From rch at umail.ucsb.edu Mon Jan 8 20:20:21 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Mon Jan 8 20:20:33 2007 Subject: [Tdg] Presentation Message-ID: <45A31805.2050406@umail.ucsb.edu> TDGers, Welcome back! Hope you all had a good break.. To get back into the swing of things, I'd first like to mention that Alex Villacorta - who is managing the IGERT seminar series - has invited us to present the MINT framework as an IGERT seminar. The dates available are: 1/19, 2/2, 2/9, 3/2 and 3/9.. Please let me know what date you prefer and if you have an interest in presenting anything MINT related. We will need to formulate an outline for the presentation soon. I think a good approach would be to basically present the mint proposal to give an overview, along with specific research areas by various groups/people. On a related note, I'd like to take a survey of when people are free this quarter for regular meetings to do programming of MINT during the day. So far, my schedule is completely open. There is a great deal we have already agreed on, and I think we are actually very near to a working core design. Happy new year, Rama From lists at grahamwakefield.net Tue Jan 9 09:24:06 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Tue Jan 9 09:26:30 2007 Subject: [Tdg] Presentation In-Reply-To: <45A31805.2050406@umail.ucsb.edu> References: <45A31805.2050406@umail.ucsb.edu> Message-ID: <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> Hi Rama & everyone My schedule: M: free after 3pm T: free all day W: busy all day Th: free all day F: free after IGERT talk (usually 2-3pm) For dates of the presentation, I'd much prefer February 9th onwards. G On Jan 8, 2007, at 8:20 PM, Rama Hoetzlein wrote: > TDGers, > > Welcome back! Hope you all had a good break.. > > To get back into the swing of things, I'd first like to mention > that Alex Villacorta - who is managing the IGERT seminar series - > has invited us to present the MINT framework as an IGERT seminar. > The dates available are: 1/19, 2/2, 2/9, 3/2 and 3/9.. > > Please let me know what date you prefer and if you have an interest > in presenting anything MINT related. We will need to formulate an > outline for the presentation soon. I think a good approach would be > to basically present the mint proposal to give an overview, along > with specific research areas by various groups/people. > > On a related note, I'd like to take a survey of when people are > free this quarter for regular meetings to do programming of MINT > during the day. So far, my schedule is completely open. There is a > great deal we have already agreed on, and I think we are actually > very near to a working core design. > > Happy new year, > Rama > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Tue Jan 9 09:35:37 2007 From: alex at neisis.net (Alex Norman) Date: Tue Jan 9 09:36:33 2007 Subject: [Tdg] Presentation In-Reply-To: <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> References: <45A31805.2050406@umail.ucsb.edu> <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> Message-ID: <20070109173537.GE26294@silverninja.net> Hello Everyone, Happy New Year! My schedule so far looks like: M: free between 1 and 4 (might become free before 4) T: free between 9:30 and 5 W: free before noon (might become all day) Th: free between 9:30 and 5 F: free before noon or after 1 (might become all day) Looks like Tuesday or Thursday mid day/afternoon might be good? I'd like to contribute to the presentation in any way that I can. -Alex On 0, Graham Wakefield wrote: > Hi Rama & everyone > > My schedule: > > M: free after 3pm > T: free all day > W: busy all day > Th: free all day > F: free after IGERT talk (usually 2-3pm) > > For dates of the presentation, I'd much prefer February 9th onwards. > > G > > On Jan 8, 2007, at 8:20 PM, Rama Hoetzlein wrote: > > >TDGers, > > > >Welcome back! Hope you all had a good break.. > > > >To get back into the swing of things, I'd first like to mention > >that Alex Villacorta - who is managing the IGERT seminar series - > >has invited us to present the MINT framework as an IGERT seminar. > >The dates available are: 1/19, 2/2, 2/9, 3/2 and 3/9.. > > > >Please let me know what date you prefer and if you have an interest > >in presenting anything MINT related. We will need to formulate an > >outline for the presentation soon. I think a good approach would be > >to basically present the mint proposal to give an overview, along > >with specific research areas by various groups/people. > > > >On a related note, I'd like to take a survey of when people are > >free this quarter for regular meetings to do programming of MINT > >during the day. So far, my schedule is completely open. There is a > >great deal we have already agreed on, and I think we are actually > >very near to a working core design. > > > >Happy new year, > >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 Tue Jan 9 10:02:13 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Tue Jan 9 10:03:13 2007 Subject: [Tdg] Presentation In-Reply-To: <20070109173537.GE26294@silverninja.net> References: <45A31805.2050406@umail.ucsb.edu> <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> <20070109173537.GE26294@silverninja.net> Message-ID: <1079b050701091002s5220cd97icf24714d3d92c391@mail.gmail.com> I would got for Tue and Thu as well. I'm with Graham on presentation time too. wes On 1/9/07, Alex Norman wrote: > Hello Everyone, Happy New Year! > > My schedule so far looks like: > M: free between 1 and 4 (might become free before 4) > T: free between 9:30 and 5 > W: free before noon (might become all day) > Th: free between 9:30 and 5 > F: free before noon or after 1 (might become all day) > > Looks like Tuesday or Thursday mid day/afternoon might be good? > > I'd like to contribute to the presentation in any way that I can. > > -Alex > > On 0, Graham Wakefield wrote: > > Hi Rama & everyone > > > > My schedule: > > > > M: free after 3pm > > T: free all day > > W: busy all day > > Th: free all day > > F: free after IGERT talk (usually 2-3pm) > > > > For dates of the presentation, I'd much prefer February 9th onwards. > > > > G > > > > On Jan 8, 2007, at 8:20 PM, Rama Hoetzlein wrote: > > > > >TDGers, > > > > > >Welcome back! Hope you all had a good break.. > > > > > >To get back into the swing of things, I'd first like to mention > > >that Alex Villacorta - who is managing the IGERT seminar series - > > >has invited us to present the MINT framework as an IGERT seminar. > > >The dates available are: 1/19, 2/2, 2/9, 3/2 and 3/9.. > > > > > >Please let me know what date you prefer and if you have an interest > > >in presenting anything MINT related. We will need to formulate an > > >outline for the presentation soon. I think a good approach would be > > >to basically present the mint proposal to give an overview, along > > >with specific research areas by various groups/people. > > > > > >On a related note, I'd like to take a survey of when people are > > >free this quarter for regular meetings to do programming of MINT > > >during the day. So far, my schedule is completely open. There is a > > >great deal we have already agreed on, and I think we are actually > > >very near to a working core design. > > > > > >Happy new year, > > >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 ljputnam at umail.ucsb.edu Tue Jan 9 10:18:49 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Tue Jan 9 10:19:51 2007 Subject: [Tdg] Presentation In-Reply-To: <1079b050701091002s5220cd97icf24714d3d92c391@mail.gmail.com> References: <45A31805.2050406@umail.ucsb.edu> <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> <20070109173537.GE26294@silverninja.net> <1079b050701091002s5220cd97icf24714d3d92c391@mail.gmail.com> Message-ID: <20070109101849.08l9ytno08w4goww@webaccess.umail.ucsb.edu> ditto on everything. Lance Wesley Smith wrote: > I would got for Tue and Thu as well. I'm with Graham on presentation > time too. > > wes > > On 1/9/07, Alex Norman wrote: >> Hello Everyone, Happy New Year! >> >> My schedule so far looks like: >> M: free between 1 and 4 (might become free before 4) >> T: free between 9:30 and 5 >> W: free before noon (might become all day) >> Th: free between 9:30 and 5 >> F: free before noon or after 1 (might become all day) >> >> Looks like Tuesday or Thursday mid day/afternoon might be good? >> >> I'd like to contribute to the presentation in any way that I can. >> >> -Alex >> >> On 0, Graham Wakefield wrote: >>> Hi Rama & everyone >>> >>> My schedule: >>> >>> M: free after 3pm >>> T: free all day >>> W: busy all day >>> Th: free all day >>> F: free after IGERT talk (usually 2-3pm) >>> >>> For dates of the presentation, I'd much prefer February 9th onwards. >>> >>> G >>> >>> On Jan 8, 2007, at 8:20 PM, Rama Hoetzlein wrote: >>> >>> >TDGers, >>> > >>> >Welcome back! Hope you all had a good break.. >>> > >>> >To get back into the swing of things, I'd first like to mention >>> >that Alex Villacorta - who is managing the IGERT seminar series - >>> >has invited us to present the MINT framework as an IGERT seminar. >>> >The dates available are: 1/19, 2/2, 2/9, 3/2 and 3/9.. >>> > >>> >Please let me know what date you prefer and if you have an interest >>> >in presenting anything MINT related. We will need to formulate an >>> >outline for the presentation soon. I think a good approach would be >>> >to basically present the mint proposal to give an overview, along >>> >with specific research areas by various groups/people. >>> > >>> >On a related note, I'd like to take a survey of when people are >>> >free this quarter for regular meetings to do programming of MINT >>> >during the day. So far, my schedule is completely open. There is a >>> >great deal we have already agreed on, and I think we are actually >>> >very near to a working core design. >>> > >>> >Happy new year, >>> >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 >> > _______________________________________________ > 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 wesley.hoke at gmail.com Tue Jan 9 10:25:27 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Tue Jan 9 10:26:24 2007 Subject: [Tdg] Presentation In-Reply-To: <20070109101849.08l9ytno08w4goww@webaccess.umail.ucsb.edu> References: <45A31805.2050406@umail.ucsb.edu> <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> <20070109173537.GE26294@silverninja.net> <1079b050701091002s5220cd97icf24714d3d92c391@mail.gmail.com> <20070109101849.08l9ytno08w4goww@webaccess.umail.ucsb.edu> Message-ID: <1079b050701091025qd815a24yd8e179c1597a6ed9@mail.gmail.com> How about a meeting on Thursday to discuss current state and prepare our IGERT battle plans? What time is good for everyone? I'm open to any time but would prefer a range from 10-3. wes On 1/9/07, Lance J. Putnam wrote: > ditto on everything. > > Lance > > Wesley Smith wrote: > > > I would got for Tue and Thu as well. I'm with Graham on presentation > > time too. > > > > wes > > > > On 1/9/07, Alex Norman wrote: > >> Hello Everyone, Happy New Year! > >> > >> My schedule so far looks like: > >> M: free between 1 and 4 (might become free before 4) > >> T: free between 9:30 and 5 > >> W: free before noon (might become all day) > >> Th: free between 9:30 and 5 > >> F: free before noon or after 1 (might become all day) > >> > >> Looks like Tuesday or Thursday mid day/afternoon might be good? > >> > >> I'd like to contribute to the presentation in any way that I can. > >> > >> -Alex > >> > >> On 0, Graham Wakefield wrote: > >>> Hi Rama & everyone > >>> > >>> My schedule: > >>> > >>> M: free after 3pm > >>> T: free all day > >>> W: busy all day > >>> Th: free all day > >>> F: free after IGERT talk (usually 2-3pm) > >>> > >>> For dates of the presentation, I'd much prefer February 9th onwards. > >>> > >>> G > >>> > >>> On Jan 8, 2007, at 8:20 PM, Rama Hoetzlein wrote: > >>> > >>> >TDGers, > >>> > > >>> >Welcome back! Hope you all had a good break.. > >>> > > >>> >To get back into the swing of things, I'd first like to mention > >>> >that Alex Villacorta - who is managing the IGERT seminar series - > >>> >has invited us to present the MINT framework as an IGERT seminar. > >>> >The dates available are: 1/19, 2/2, 2/9, 3/2 and 3/9.. > >>> > > >>> >Please let me know what date you prefer and if you have an interest > >>> >in presenting anything MINT related. We will need to formulate an > >>> >outline for the presentation soon. I think a good approach would be > >>> >to basically present the mint proposal to give an overview, along > >>> >with specific research areas by various groups/people. > >>> > > >>> >On a related note, I'd like to take a survey of when people are > >>> >free this quarter for regular meetings to do programming of MINT > >>> >during the day. So far, my schedule is completely open. There is a > >>> >great deal we have already agreed on, and I think we are actually > >>> >very near to a working core design. > >>> > > >>> >Happy new year, > >>> >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 > >> > > _______________________________________________ > > 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 alex at neisis.net Tue Jan 9 10:28:04 2007 From: alex at neisis.net (Alex Norman) Date: Tue Jan 9 10:28:59 2007 Subject: [Tdg] Presentation In-Reply-To: <1079b050701091025qd815a24yd8e179c1597a6ed9@mail.gmail.com> References: <45A31805.2050406@umail.ucsb.edu> <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> <20070109173537.GE26294@silverninja.net> <1079b050701091002s5220cd97icf24714d3d92c391@mail.gmail.com> <20070109101849.08l9ytno08w4goww@webaccess.umail.ucsb.edu> <1079b050701091025qd815a24yd8e179c1597a6ed9@mail.gmail.com> Message-ID: <20070109182804.GG26294@silverninja.net> I'm into that, we could make it a lunch meeting at noon? -Alex On 0, Wesley Smith wrote: > How about a meeting on Thursday to discuss current state and prepare > our IGERT battle plans? What time is good for everyone? I'm open to > any time but would prefer a range from 10-3. > > wes > > On 1/9/07, Lance J. Putnam wrote: > >ditto on everything. > > > >Lance > > > >Wesley Smith wrote: > > > >> I would got for Tue and Thu as well. I'm with Graham on presentation > >> time too. > >> > >> wes > >> > >> On 1/9/07, Alex Norman wrote: > >>> Hello Everyone, Happy New Year! > >>> > >>> My schedule so far looks like: > >>> M: free between 1 and 4 (might become free before 4) > >>> T: free between 9:30 and 5 > >>> W: free before noon (might become all day) > >>> Th: free between 9:30 and 5 > >>> F: free before noon or after 1 (might become all day) > >>> > >>> Looks like Tuesday or Thursday mid day/afternoon might be good? > >>> > >>> I'd like to contribute to the presentation in any way that I can. > >>> > >>> -Alex > >>> > >>> On 0, Graham Wakefield wrote: > >>>> Hi Rama & everyone > >>>> > >>>> My schedule: > >>>> > >>>> M: free after 3pm > >>>> T: free all day > >>>> W: busy all day > >>>> Th: free all day > >>>> F: free after IGERT talk (usually 2-3pm) > >>>> > >>>> For dates of the presentation, I'd much prefer February 9th onwards. > >>>> > >>>> G > >>>> > >>>> On Jan 8, 2007, at 8:20 PM, Rama Hoetzlein wrote: > >>>> > >>>> >TDGers, > >>>> > > >>>> >Welcome back! Hope you all had a good break.. > >>>> > > >>>> >To get back into the swing of things, I'd first like to mention > >>>> >that Alex Villacorta - who is managing the IGERT seminar series - > >>>> >has invited us to present the MINT framework as an IGERT seminar. > >>>> >The dates available are: 1/19, 2/2, 2/9, 3/2 and 3/9.. > >>>> > > >>>> >Please let me know what date you prefer and if you have an interest > >>>> >in presenting anything MINT related. We will need to formulate an > >>>> >outline for the presentation soon. I think a good approach would be > >>>> >to basically present the mint proposal to give an overview, along > >>>> >with specific research areas by various groups/people. > >>>> > > >>>> >On a related note, I'd like to take a survey of when people are > >>>> >free this quarter for regular meetings to do programming of MINT > >>>> >during the day. So far, my schedule is completely open. There is a > >>>> >great deal we have already agreed on, and I think we are actually > >>>> >very near to a working core design. > >>>> > > >>>> >Happy new year, > >>>> >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 > >>> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Wed Jan 10 14:47:55 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Wed Jan 10 14:48:56 2007 Subject: [Tdg] Presentation In-Reply-To: <20070109182804.GG26294@silverninja.net> References: <45A31805.2050406@umail.ucsb.edu> <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> <20070109173537.GE26294@silverninja.net> <1079b050701091002s5220cd97icf24714d3d92c391@mail.gmail.com> <20070109101849.08l9ytno08w4goww@webaccess.umail.ucsb.edu> <1079b050701091025qd815a24yd8e179c1597a6ed9@mail.gmail.com> <20070109182804.GG26294@silverninja.net> Message-ID: <45A56D1B.7040008@umail.ucsb.edu> Sounds good.. So noon on thursday (tomorrow)? How about we meet at Nicoletti's and go from there. Does anyone know if we have a Wiki yet? I'd really like to start posting design stuff as we go. Rama Alex Norman wrote: >I'm into that, we could make it a lunch meeting at noon? > >-Alex > >On 0, Wesley Smith wrote: > > >>How about a meeting on Thursday to discuss current state and prepare >>our IGERT battle plans? What time is good for everyone? I'm open to >>any time but would prefer a range from 10-3. >> >>wes >> >>On 1/9/07, Lance J. Putnam wrote: >> >> >>>ditto on everything. >>> >>>Lance >>> >>>Wesley Smith wrote: >>> >>> >>> >>>>I would got for Tue and Thu as well. I'm with Graham on presentation >>>>time too. >>>> >>>>wes >>>> >>>>On 1/9/07, Alex Norman wrote: >>>> >>>> >>>>>Hello Everyone, Happy New Year! >>>>> >>>>>My schedule so far looks like: >>>>>M: free between 1 and 4 (might become free before 4) >>>>>T: free between 9:30 and 5 >>>>>W: free before noon (might become all day) >>>>>Th: free between 9:30 and 5 >>>>>F: free before noon or after 1 (might become all day) >>>>> >>>>>Looks like Tuesday or Thursday mid day/afternoon might be good? >>>>> >>>>>I'd like to contribute to the presentation in any way that I can. >>>>> >>>>>-Alex >>>>> >>>>>On 0, Graham Wakefield wrote: >>>>> >>>>> >>>>>>Hi Rama & everyone >>>>>> >>>>>>My schedule: >>>>>> >>>>>>M: free after 3pm >>>>>>T: free all day >>>>>>W: busy all day >>>>>>Th: free all day >>>>>>F: free after IGERT talk (usually 2-3pm) >>>>>> >>>>>>For dates of the presentation, I'd much prefer February 9th onwards. >>>>>> >>>>>>G >>>>>> >>>>>>On Jan 8, 2007, at 8:20 PM, Rama Hoetzlein wrote: >>>>>> >>>>>> >>>>>> >>>>>>>TDGers, >>>>>>> >>>>>>>Welcome back! Hope you all had a good break.. >>>>>>> >>>>>>>To get back into the swing of things, I'd first like to mention >>>>>>>that Alex Villacorta - who is managing the IGERT seminar series - >>>>>>>has invited us to present the MINT framework as an IGERT seminar. >>>>>>>The dates available are: 1/19, 2/2, 2/9, 3/2 and 3/9.. >>>>>>> >>>>>>>Please let me know what date you prefer and if you have an interest >>>>>>>in presenting anything MINT related. We will need to formulate an >>>>>>>outline for the presentation soon. I think a good approach would be >>>>>>>to basically present the mint proposal to give an overview, along >>>>>>>with specific research areas by various groups/people. >>>>>>> >>>>>>>On a related note, I'd like to take a survey of when people are >>>>>>>free this quarter for regular meetings to do programming of MINT >>>>>>>during the day. So far, my schedule is completely open. There is a >>>>>>>great deal we have already agreed on, and I think we are actually >>>>>>>very near to a working core design. >>>>>>> >>>>>>>Happy new year, >>>>>>>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 >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>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 >>> >>> >>> >>_______________________________________________ >>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 Wed Jan 10 18:12:20 2007 From: alex at neisis.net (Alex Norman) Date: Wed Jan 10 18:13:17 2007 Subject: [Tdg] Presentation + wiki In-Reply-To: <45A56D1B.7040008@umail.ucsb.edu> References: <45A31805.2050406@umail.ucsb.edu> <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> <20070109173537.GE26294@silverninja.net> <1079b050701091002s5220cd97icf24714d3d92c391@mail.gmail.com> <20070109101849.08l9ytno08w4goww@webaccess.umail.ucsb.edu> <1079b050701091025qd815a24yd8e179c1597a6ed9@mail.gmail.com> <20070109182804.GG26294@silverninja.net> <45A56D1B.7040008@umail.ucsb.edu> Message-ID: <20070111021220.GQ26294@silverninja.net> Sounds good, Yes, as I posted earlier the wiki is working, tdg.mat.ucsb.edu add yourself as a user.. soon I should make it so that people cannot add themselves but I'll let another week or two go before I do that. -Alex On 0, Rama Hoetzlein wrote: > Sounds good.. So noon on thursday (tomorrow)? How about we meet at > Nicoletti's and go from there. > > Does anyone know if we have a Wiki yet? I'd really like to start posting > design stuff as we go. > > Rama > > Alex Norman wrote: > > >I'm into that, we could make it a lunch meeting at noon? > > > >-Alex > > > >On 0, Wesley Smith wrote: > > > > > >>How about a meeting on Thursday to discuss current state and prepare > >>our IGERT battle plans? What time is good for everyone? I'm open to > >>any time but would prefer a range from 10-3. > >> > >>wes > >> > >>On 1/9/07, Lance J. Putnam wrote: > >> > >> > >>>ditto on everything. > >>> > >>>Lance > >>> > >>>Wesley Smith wrote: > >>> > >>> > >>> > >>>>I would got for Tue and Thu as well. I'm with Graham on presentation > >>>>time too. > >>>> > >>>>wes > >>>> > >>>>On 1/9/07, Alex Norman wrote: > >>>> > >>>> > >>>>>Hello Everyone, Happy New Year! > >>>>> > >>>>>My schedule so far looks like: > >>>>>M: free between 1 and 4 (might become free before 4) > >>>>>T: free between 9:30 and 5 > >>>>>W: free before noon (might become all day) > >>>>>Th: free between 9:30 and 5 > >>>>>F: free before noon or after 1 (might become all day) > >>>>> > >>>>>Looks like Tuesday or Thursday mid day/afternoon might be good? > >>>>> > >>>>>I'd like to contribute to the presentation in any way that I can. > >>>>> > >>>>>-Alex > >>>>> > >>>>>On 0, Graham Wakefield wrote: > >>>>> > >>>>> > >>>>>>Hi Rama & everyone > >>>>>> > >>>>>>My schedule: > >>>>>> > >>>>>>M: free after 3pm > >>>>>>T: free all day > >>>>>>W: busy all day > >>>>>>Th: free all day > >>>>>>F: free after IGERT talk (usually 2-3pm) > >>>>>> > >>>>>>For dates of the presentation, I'd much prefer February 9th onwards. > >>>>>> > >>>>>>G > >>>>>> > >>>>>>On Jan 8, 2007, at 8:20 PM, Rama Hoetzlein wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>TDGers, > >>>>>>> > >>>>>>>Welcome back! Hope you all had a good break.. > >>>>>>> > >>>>>>>To get back into the swing of things, I'd first like to mention > >>>>>>>that Alex Villacorta - who is managing the IGERT seminar series - > >>>>>>>has invited us to present the MINT framework as an IGERT seminar. > >>>>>>>The dates available are: 1/19, 2/2, 2/9, 3/2 and 3/9.. > >>>>>>> > >>>>>>>Please let me know what date you prefer and if you have an interest > >>>>>>>in presenting anything MINT related. We will need to formulate an > >>>>>>>outline for the presentation soon. I think a good approach would be > >>>>>>>to basically present the mint proposal to give an overview, along > >>>>>>>with specific research areas by various groups/people. > >>>>>>> > >>>>>>>On a related note, I'd like to take a survey of when people are > >>>>>>>free this quarter for regular meetings to do programming of MINT > >>>>>>>during the day. So far, my schedule is completely open. There is a > >>>>>>>great deal we have already agreed on, and I think we are actually > >>>>>>>very near to a working core design. > >>>>>>> > >>>>>>>Happy new year, > >>>>>>>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 > >>>>> > >>>>> > >>>>> > >>>>_______________________________________________ > >>>>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 > >>> > >>> > >>> > >>_______________________________________________ > >>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 Thu Jan 11 15:52:19 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Thu Jan 11 15:53:16 2007 Subject: [Tdg] paper Message-ID: <1079b050701111552m31229aadkfd5b0a36c75f1394@mail.gmail.com> ARMI: An Adaptive, Platform Independent Communication Library http://parasol.tamu.edu/publications/download.php?file_id=368 wes From rch at umail.ucsb.edu Mon Jan 15 13:32:27 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Mon Jan 15 13:34:45 2007 Subject: [Tdg] Update In-Reply-To: <45A56D1B.7040008@umail.ucsb.edu> References: <45A31805.2050406@umail.ucsb.edu> <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> <20070109173537.GE26294@silverninja.net> <1079b050701091002s5220cd97icf24714d3d92c391@mail.gmail.com> <20070109101849.08l9ytno08w4goww@webaccess.umail.ucsb.edu> <1079b050701091025qd815a24yd8e179c1597a6ed9@mail.gmail.com> <20070109182804.GG26294@silverninja.net> <45A56D1B.7040008@umail.ucsb.edu> Message-ID: <45ABF2EB.20904@umail.ucsb.edu> TDGers, Quick update for anyone who missed the last meeting... Every Tues & Thurs, 2-5pm - We will code and/or meet to design MINT February 9th - IGERT Presentation of MINT to faculty and students Rama From wesley.hoke at gmail.com Mon Jan 15 13:40:06 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Mon Jan 15 17:25:41 2007 Subject: [Tdg] Update In-Reply-To: <45ABF2EB.20904@umail.ucsb.edu> References: <45A31805.2050406@umail.ucsb.edu> <48D70410-0AB2-42D3-8636-C7FA78169FB0@grahamwakefield.net> <20070109173537.GE26294@silverninja.net> <1079b050701091002s5220cd97icf24714d3d92c391@mail.gmail.com> <20070109101849.08l9ytno08w4goww@webaccess.umail.ucsb.edu> <1079b050701091025qd815a24yd8e179c1597a6ed9@mail.gmail.com> <20070109182804.GG26294@silverninja.net> <45A56D1B.7040008@umail.ucsb.edu> <45ABF2EB.20904@umail.ucsb.edu> Message-ID: <1079b050701151340q4d6a4690te79529be30d71adc@mail.gmail.com> Here's the diagram we made discussing the event system and threads on Thursday in borth OmniGraffle and PNG format. Feel free to add to it. wes On 1/15/07, Rama Hoetzlein wrote: > TDGers, > > Quick update for anyone who missed the last meeting... > > Every Tues & Thurs, 2-5pm - We will code and/or meet to design MINT > February 9th - IGERT Presentation of MINT to faculty and students > > Rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > -------------- next part -------------- A non-text attachment was scrubbed... Name: TDG_EventSystem.zip Type: application/zip Size: 61838 bytes Desc: not available Url : http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070115/d4e20ff4/TDG_EventSystem-0001.zip From rch at umail.ucsb.edu Mon Jan 15 22:57:06 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Mon Jan 15 22:59:36 2007 Subject: [Tdg] Wiki up! Message-ID: <45AC7742.6040705@umail.ucsb.edu> Hey all, I've put a whole bunch of stuff up on our new wiki (thanks Alex)... Check it out: http://tdg.mat.ucsb.edu Since it is all of our design materials, we might want to think about password protecting it soon. R From jcastellanos at umail.ucsb.edu Mon Jan 15 23:17:31 2007 From: jcastellanos at umail.ucsb.edu (Jorge Castellanos) Date: Mon Jan 15 23:19:54 2007 Subject: [Tdg] Wiki up! In-Reply-To: <45AC7742.6040705@umail.ucsb.edu> References: <45AC7742.6040705@umail.ucsb.edu> Message-ID: <2DFC734B-B508-4BDB-A456-8F89084811FA@umail.ucsb.edu> Thanks Rama & Alex (& wes for sending the diagrams) So.. how is the core programming going to be approached? Cuz' I'm ready to start coding. I propose having a TODO list where people can take things from the list. This can be done either per file, or per subsystem. This way, even those that can't attend to the meetings (e.g. me) can advance in the coding part by reading stuff that has to be done (or fixed... maybe a separate bug database has to be created) Any thoughts? j On Jan 16, 2007, at 1:57 AM, Rama Hoetzlein wrote: Hey all, I've put a whole bunch of stuff up on our new wiki (thanks Alex)... Check it out: http://tdg.mat.ucsb.edu Since it is all of our design materials, we might want to think about password protecting it soon. R _______________________________________________ Tdg mailing list Tdg@mat.ucsb.edu http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Tue Jan 16 12:36:27 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Tue Jan 16 12:38:50 2007 Subject: [Tdg] Meeting Message-ID: <1079b050701161236m3e524a7an891e7cbed763af70@mail.gmail.com> Hi folks, Can't make it today but I will be there on Thurs. wes From alex at neisis.net Tue Jan 16 13:41:44 2007 From: alex at neisis.net (Alex Norman) Date: Tue Jan 16 13:44:00 2007 Subject: [Tdg] Wiki up! In-Reply-To: <45AC7742.6040705@umail.ucsb.edu> References: <45AC7742.6040705@umail.ucsb.edu> Message-ID: <20070116214144.GC510@silverninja.net> I've just disabled anonymous people from adding/editing content and adding logins, but users (ie you) should be able to add logins. -Alex On 0, Rama Hoetzlein wrote: > Hey all, > > I've put a whole bunch of stuff up on our new wiki (thanks Alex)... > Check it out: > http://tdg.mat.ucsb.edu > > Since it is all of our design materials, we might want to think about > password protecting it soon. > > R > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From lists at grahamwakefield.net Tue Jan 16 13:59:39 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Tue Jan 16 14:03:21 2007 Subject: [Tdg] Meeting In-Reply-To: <1079b050701161236m3e524a7an891e7cbed763af70@mail.gmail.com> References: <1079b050701161236m3e524a7an891e7cbed763af70@mail.gmail.com> Message-ID: Likewise On Jan 16, 2007, at 12:36 PM, Wesley Smith wrote: > Hi folks, > Can't make it today but I will be there on Thurs. > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Thu Jan 18 18:00:10 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Thu Jan 18 18:02:35 2007 Subject: [Tdg] Core Coding Message-ID: <45B0262A.1020204@umail.ucsb.edu> Heyall, I just realized something after our meeting today... The issue of coding the core has been a tricky one. But what I realized is the core IS modular.. I mean, we need certain things that do just one thing, but well.. So, if each of us was willing to write some small piece of core, it would go much faster.. Here are the (modular) pieces I'm talking about.. Basically a core to-do list: 1. Memory Pool - We need a memory pool class that will Alloc and Free memory from a pool. The internal mechanisms are up to the implementor, but it should 1) Be fast (possibly by preallocating data), 2) Allow for postponed deletion, 3) Possibly provide Alloc/Free functions that lock (optional). Everything else is up to the implementor.. The type of data allocated/freed is arbitrary. 2. EventQueue - We need a fast queue that we can add and remove events from. It must allow for thread-safe read locking (ie. sub-systems are briefly locked from Dequeuing, but Queue always succeeds). That is, the minimum functionality is: Queue - Add event to queue. Always succeeds. May briefly lock the queue from read while it writes. Dequeue - Remove event from queue. Fails if queue is locked. This follows our strategy of "lock on write", that is - lock when a subsystem calls Queue. The implementor choose to greatly minimize locking by doing a double-buffering strategy. 3. Timer - We need a cross-platform, high performance timer. It should provide the following functions, at minimum: GetPerformanceTimer - Queries a high performance system timer on any platform GetSystemTime - Returns the system time. We need to define what a time stamp is, but then it could be implemented. 4. Scheduler - Our scheduler should have two things (member variables): 1) Timer, and 2) Process list. The Process list is already implemented in the core code. The scheduler needs to 1) repeatedly check the wake-up times of Processes using the high peformance Timer, 2) call a Process callbacks and/or event handler when they are scheduled to wake up. These really are very seperable pieces. Event Handler is not included because the Event Handler is basically all these things combined, ie. it is finished when the above is finished. The only final piece is to grab Events from EventQueue and multiplex them to sub-systems. I say we each pick one : ).. I'm interested in the Scheduler, but wouldn't mind working on the Event Queue too. Rama From lists at grahamwakefield.net Thu Jan 18 18:28:08 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Thu Jan 18 18:31:02 2007 Subject: [Tdg] Core Coding In-Reply-To: <45B0262A.1020204@umail.ucsb.edu> References: <45B0262A.1020204@umail.ucsb.edu> Message-ID: <09F9FB55-56DA-4106-B557-0C51188C4C16@grahamwakefield.net> Hi, Good idea. Sorry I couldn't be there today. Another component: Handler registration. A generic way to register an object as a handler of events (possibly of events of certain types), within the listener-list of any other object that can generate events (another generic class type?) I'd be interested in working on the EventQueue, or Scheduler, or something about the EventHandler code. Q: is the Scheduler a singleton, or do different processes have different schedulers? I know that the audio process runs as a callback from the OS audio system, so it will wake itself up. Other subsystems might do the same; so the Scheduler will need to be able to communicate with 'self-scheduling' processes like this too. Q: how soon do we need to decide the basic event data structure / interface? About the Event Handler: How do we register a component's handler with another component? I think the Event Handler has a bigger scope (more generic) type than just for subsystems. Say, I have a OS Window that will receive a keyboard event, and it might have a GLV context and some user-level game code associated with it, then the keyboard event might need to be forwarded to the GLV context first, and if unhandled, to the user's game code, and if unhandled, to the main application's handler. So we need to support dynamic nested hierarchies of handlers (including setting order of calls), not just hard-coded ones in subsystems. Do we want to register a handler and at the same time set flags for particular types of events it will respond to, or should a handler receive all events and simply return a code if not handled? On Jan 18, 2007, at 6:00 PM, Rama Hoetzlein wrote: > Heyall, > > I just realized something after our meeting today... The issue of > coding the core has been a tricky one. But what I realized is the > core IS modular.. I mean, we need certain things that do just one > thing, but well.. So, if each of us was willing to write some small > piece of core, it would go much faster.. > > Here are the (modular) pieces I'm talking about.. Basically a core > to-do list: > > 1. Memory Pool - We need a memory pool class that will Alloc and > Free memory from a pool. The internal mechanisms are up to the > implementor, but it should 1) Be fast (possibly by preallocating > data), 2) Allow for postponed deletion, 3) Possibly provide Alloc/ > Free functions that lock (optional). Everything else is up to the > implementor.. The type of data allocated/freed is arbitrary. > > 2. EventQueue - We need a fast queue that we can add and remove > events from. It must allow for thread-safe read locking (ie. sub- > systems are briefly locked from Dequeuing, but Queue always > succeeds). That is, the minimum functionality is: > Queue - Add event to queue. Always succeeds. May briefly lock the > queue from read while it writes. > Dequeue - Remove event from queue. Fails if queue is locked. > This follows our strategy of "lock on write", that is - lock when a > subsystem calls Queue. The implementor choose to greatly minimize > locking by doing a double-buffering strategy. > > 3. Timer - We need a cross-platform, high performance timer. It > should provide the following functions, at minimum: > GetPerformanceTimer - Queries a high performance system timer on > any platform > GetSystemTime - Returns the system time. > We need to define what a time stamp is, but then it could be > implemented. > > 4. Scheduler - Our scheduler should have two things (member > variables): 1) Timer, and 2) Process list. The Process list is > already implemented in the core code. The scheduler needs to 1) > repeatedly check the wake-up times of Processes using the high > peformance Timer, 2) call a Process callbacks and/or event handler > when they are scheduled to wake up. > > These really are very seperable pieces. Event Handler is not > included because the Event Handler is basically all these things > combined, ie. it is finished when the above is finished. The only > final piece is to grab Events from EventQueue and multiplex them to > sub-systems. > > I say we each pick one : ).. I'm interested in the Scheduler, but > wouldn't mind working on the Event Queue too. > > Rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Thu Jan 18 20:15:31 2007 From: alex at neisis.net (Alex Norman) Date: Thu Jan 18 20:17:49 2007 Subject: [Tdg] abstracting main Message-ID: <20070119041531.GN3802@silverninja.net> I'm not sure if I'm in the minority (it seems like I usually am) but I don't see why mint should abstract "main" or "winmain" or whatever your OS's entry point to apps is. That has nothing to do with multimedia. I DO agree that that can be a useful thing, but I really see this as totally separate from Mint and think that incorporating it in mint is bloat. I think this sort of thing would be good to make into a separate library (a crossplatform "main"), and could be used in Mint examples, but should not be part of the "core". This would be useful for a lot of other applications that are not mint related too. -Alex From rch at umail.ucsb.edu Thu Jan 18 20:16:06 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Thu Jan 18 20:18:19 2007 Subject: [Tdg] Core Coding In-Reply-To: <09F9FB55-56DA-4106-B557-0C51188C4C16@grahamwakefield.net> References: <45B0262A.1020204@umail.ucsb.edu> <09F9FB55-56DA-4106-B557-0C51188C4C16@grahamwakefield.net> Message-ID: <45B04606.80907@umail.ucsb.edu> > Another component: Handler registration. A generic way to register > an object as a handler of events (possibly of events of certain > types), within the listener-list of any other object that can > generate events (another generic class type?) I have this already. You should check it out. Perhaps there is something more it needs to be able to do. However, I don't think that every subsystem should have a listener-list. Only the core Scheduler. > Q: is the Scheduler a singleton, or do different processes have > different schedulers? I know that the audio process runs as a > callback from the OS audio system, so it will wake itself up. Other > subsystems might do the same; so the Scheduler will need to be able > to communicate with 'self-scheduling' processes like this too. I think the core Scheduler itself is a singleton, but there might be several processes that the Scheduler is keeping track of. A scheduler manages processes. As mentioned, a prototype of this is already written (ie. i have a list of processes with registered callbacks). I just haven't done the wake-up part yet because I need the Timer. Question: How do we handle the situation where the user calls audio.Disable? This should, theoretically, stop the audio callback thread. If the user calls audio.Enable, the thread should go back on, right? As i understand it, some portion of the audio sub-system >must< be called directly from the core-thread, such as setting up portaudio, etc. How do we handle events at this level (high-level portaudio stuff)? > Q: how soon do we need to decide the basic event data structure / > interface? Alex and I made some progress on this over the past week... we can discuss sometime. > How do we register a component's handler with another component? If by component you mean sub-system, then I think there is only one registration that takes place. The subsystem registers the handler with the core. Based on our current strategy of the core being the central handler of stuff, subsystem should not register handlers with each other. (PS. what is a "component"?) > I think the Event Handler has a bigger scope (more generic) type than > just for subsystems. Say, I have a OS Window that will receive a > keyboard event, and it might have a GLV context and some user-level > game code associated with it, then the keyboard event might need to > be forwarded to the GLV context first, and if unhandled, to the > user's game code, and if unhandled, to the main application's > handler. So we need to support dynamic nested hierarchies of > handlers (including setting order of calls), not just hard-coded ones > in subsystems. I'd really like to see a set of sample scenarios for how events more around before we decide on this. All I know right now -- with certainty -- is the Renderer gets RenderEvents and nothing else (because it can't handle anything else). If you want some keyboard event to change the renderer state (L = enable lighting), then the userEventHandler receives the 'L' KeyEvent and calls SetLighting, which generates SetLightingEvent. The user just writes this: void userEventHandler (Event* e ) { case KeyEvent: if (e->getKey() == 'L' ) win.ToggleLighting (); // this generates a ToggleLightingEvent } Don't all sub-systems operate this way? > Do we want to register a handler and at the same time set flags for > particular types of events it will respond to, or should a handler > receive all events and simply return a code if not handled? The latter, I think. Rama From rch at umail.ucsb.edu Thu Jan 18 20:24:07 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Thu Jan 18 20:26:20 2007 Subject: [Tdg] abstracting main In-Reply-To: <20070119041531.GN3802@silverninja.net> References: <20070119041531.GN3802@silverninja.net> Message-ID: <45B047E7.6010609@umail.ucsb.edu> What's the problem with the BUILD_OSMAIN solution we did? It would let you write the OS main that you want, and basically turn off all that abstraction. I think a lot of people, especially beginners, are going to want this. I'd like my apps (stuff I create with MINT) to compile on different platforms without having to provide a different main for each. Rama Alex Norman wrote: >I'm not sure if I'm in the minority (it seems like I usually am) but I don't see >why mint should abstract "main" or "winmain" or whatever your OS's entry point >to apps is. That has nothing to do with multimedia. > >I DO agree that that can be a useful thing, but I really see this as totally >separate from Mint and think that incorporating it in mint is bloat. > >I think this sort of thing would be good to make into a separate library (a >crossplatform "main"), and could be used in Mint examples, but should not be >part of the "core". This would be useful for a lot of other applications that >are not mint related too. > >-Alex >_______________________________________________ >Tdg mailing list >Tdg@mat.ucsb.edu >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > From lists at grahamwakefield.net Thu Jan 18 22:23:38 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Thu Jan 18 22:26:31 2007 Subject: [Tdg] Core Coding In-Reply-To: <45B04606.80907@umail.ucsb.edu> References: <45B0262A.1020204@umail.ucsb.edu> <09F9FB55-56DA-4106-B557-0C51188C4C16@grahamwakefield.net> <45B04606.80907@umail.ucsb.edu> Message-ID: On Jan 18, 2007, at 8:16 PM, Rama Hoetzlein wrote: > >> Another component: Handler registration. A generic way to >> register an object as a handler of events (possibly of events of >> certain types), within the listener-list of any other object that >> can generate events (another generic class type?) > > I have this already. You should check it out. Perhaps there is > something more it needs to be able to do. However, I don't think > that every subsystem should have a listener-list. Only the core > Scheduler. Ok. > >> Q: is the Scheduler a singleton, or do different processes have >> different schedulers? I know that the audio process runs as a >> callback from the OS audio system, so it will wake itself up. >> Other subsystems might do the same; so the Scheduler will need to >> be able to communicate with 'self-scheduling' processes like this >> too. > > I think the core Scheduler itself is a singleton, but there might > be several processes that the Scheduler is keeping track of. A > scheduler manages processes. As mentioned, a prototype of this is > already written (ie. i have a list of processes with registered > callbacks). I just haven't done the wake-up part yet because I need > the Timer. > > Question: How do we handle the situation where the user calls > audio.Disable? This should, theoretically, stop the audio callback > thread. If the user calls audio.Enable, the thread should go back > on, right? As i understand it, some portion of the audio sub-system > >must< be called directly from the core-thread, such as setting up > portaudio, etc. How do we handle events at this level (high-level > portaudio stuff)? So, the audio process needs a very low priority, low frequency, main thread event listener, for audio.enable etc., but it also has a very high priority, high frequency audio thread event listener for messages to the audio process (e.g. midi notes to sonify). Similar issues will probably apply to other subsystems I expect. > >> Q: how soon do we need to decide the basic event data structure / >> interface? > > Alex and I made some progress on this over the past week... we can > discuss sometime. Cool. > >> How do we register a component's handler with another component? > > If by component you mean sub-system, then I think there is only one > registration that takes place. The subsystem registers the handler > with the core. Based on our current strategy of the core being the > central handler of stuff, subsystem should not register handlers > with each other. (PS. what is a "component"?) I meant what is implied in my example: OS Keypress -> Core -> -> OS Window 1 -> GLV context (not handled) -> User code The user's code wants to hear about the keypress in Window 1, but not if the GLV context attached to Window 1 already handled it. Core, Window, GLV and User object are all components that can receive events, and need to be registered, but I think the user code for Window 1 should be registered to Window 1, not to Core. > >> I think the Event Handler has a bigger scope (more generic) type >> than just for subsystems. Say, I have a OS Window that will >> receive a keyboard event, and it might have a GLV context and >> some user-level game code associated with it, then the keyboard >> event might need to be forwarded to the GLV context first, and if >> unhandled, to the user's game code, and if unhandled, to the main >> application's handler. So we need to support dynamic nested >> hierarchies of handlers (including setting order of calls), not >> just hard-coded ones in subsystems. > > I'd really like to see a set of sample scenarios for how events > more around before we decide on this. All I know right now -- with > certainty -- is the Renderer gets RenderEvents and nothing else > (because it can't handle anything else). If you want some keyboard > event to change the renderer state (L = enable lighting), then the > userEventHandler receives the 'L' KeyEvent and calls SetLighting, > which generates SetLightingEvent. The user just writes this: > > void userEventHandler (Event* e ) > { > case KeyEvent: if (e->getKey() == 'L' ) win.ToggleLighting > (); // this generates a ToggleLightingEvent > Don't all sub-systems operate this way? So my question is, where is this user code? And to what is it registered? Is it in a single, global place (bad idea I think) or is it in some object that is attached to the window (better idea, since it needs to know what win is, and it is much more object oriented). Is it registered to the Core directly (ok for simple apps, not good for complex apps) or is it registered to the appropriate context, i.e. the Window? Case scenario 2: user presses a midi key, and wants an oscillator to start playing based on the midi pitch & velocity (loudness). The audio process needs to receive a midi event, and interpret the event within the user's audio DSP code. > >> Do we want to register a handler and at the same time set flags >> for particular types of events it will respond to, or should a >> handler receive all events and simply return a code if not handled? > > The latter, I think. Me too. From lists at grahamwakefield.net Thu Jan 18 22:24:02 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Thu Jan 18 22:27:04 2007 Subject: [Tdg] Core Coding In-Reply-To: <45B04606.80907@umail.ucsb.edu> References: <45B0262A.1020204@umail.ucsb.edu> <09F9FB55-56DA-4106-B557-0C51188C4C16@grahamwakefield.net> <45B04606.80907@umail.ucsb.edu> Message-ID: <265D9023-A9F3-40F2-B8DE-1F72D8CB4318@grahamwakefield.net> On Jan 18, 2007, at 8:16 PM, Rama Hoetzlein wrote: > >> Another component: Handler registration. A generic way to >> register an object as a handler of events (possibly of events of >> certain types), within the listener-list of any other object that >> can generate events (another generic class type?) > > I have this already. You should check it out. Perhaps there is > something more it needs to be able to do. However, I don't think > that every subsystem should have a listener-list. Only the core > Scheduler. Ok. > >> Q: is the Scheduler a singleton, or do different processes have >> different schedulers? I know that the audio process runs as a >> callback from the OS audio system, so it will wake itself up. >> Other subsystems might do the same; so the Scheduler will need to >> be able to communicate with 'self-scheduling' processes like this >> too. > > I think the core Scheduler itself is a singleton, but there might > be several processes that the Scheduler is keeping track of. A > scheduler manages processes. As mentioned, a prototype of this is > already written (ie. i have a list of processes with registered > callbacks). I just haven't done the wake-up part yet because I need > the Timer. > > Question: How do we handle the situation where the user calls > audio.Disable? This should, theoretically, stop the audio callback > thread. If the user calls audio.Enable, the thread should go back > on, right? As i understand it, some portion of the audio sub-system > >must< be called directly from the core-thread, such as setting up > portaudio, etc. How do we handle events at this level (high-level > portaudio stuff)? So, the audio process needs a very low priority, low frequency, main thread event listener, for audio.enable etc., but it also has a very high priority, high frequency audio thread event listener for messages to the audio process (e.g. midi notes to sonify). Similar issues will probably apply to other subsystems I expect. > >> Q: how soon do we need to decide the basic event data structure / >> interface? > > Alex and I made some progress on this over the past week... we can > discuss sometime. Cool. > >> How do we register a component's handler with another component? > > If by component you mean sub-system, then I think there is only one > registration that takes place. The subsystem registers the handler > with the core. Based on our current strategy of the core being the > central handler of stuff, subsystem should not register handlers > with each other. (PS. what is a "component"?) I meant what is implied in my example: OS Keypress -> Core -> -> OS Window 1 -> GLV context (not handled) -> User code The user's code wants to hear about the keypress in Window 1, but not if the GLV context attached to Window 1 already handled it. Core, Window, GLV and User object are all components that can receive events, and need to be registered, but I think the user code for Window 1 should be registered to Window 1, not to Core. > >> I think the Event Handler has a bigger scope (more generic) type >> than just for subsystems. Say, I have a OS Window that will >> receive a keyboard event, and it might have a GLV context and >> some user-level game code associated with it, then the keyboard >> event might need to be forwarded to the GLV context first, and if >> unhandled, to the user's game code, and if unhandled, to the main >> application's handler. So we need to support dynamic nested >> hierarchies of handlers (including setting order of calls), not >> just hard-coded ones in subsystems. > > I'd really like to see a set of sample scenarios for how events > more around before we decide on this. All I know right now -- with > certainty -- is the Renderer gets RenderEvents and nothing else > (because it can't handle anything else). If you want some keyboard > event to change the renderer state (L = enable lighting), then the > userEventHandler receives the 'L' KeyEvent and calls SetLighting, > which generates SetLightingEvent. The user just writes this: > > void userEventHandler (Event* e ) > { > case KeyEvent: if (e->getKey() == 'L' ) win.ToggleLighting > (); // this generates a ToggleLightingEvent > Don't all sub-systems operate this way? So my question is, where is this user code? And to what is it registered? Is it in a single, global place (bad idea I think) or is it in some object that is attached to the window (better idea, since it needs to know what win is, and it is much more object oriented). Is it registered to the Core directly (ok for simple apps, not good for complex apps) or is it registered to the appropriate context, i.e. the Window? Case scenario 2: user presses a midi key, and wants an oscillator to start playing based on the midi pitch & velocity (loudness). The audio process needs to receive a midi event, and interpret the event within the user's audio DSP code. > >> Do we want to register a handler and at the same time set flags >> for particular types of events it will respond to, or should a >> handler receive all events and simply return a code if not handled? > > The latter, I think. Me too. From lists at grahamwakefield.net Thu Jan 18 22:24:07 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Thu Jan 18 22:27:42 2007 Subject: [Tdg] abstracting main In-Reply-To: <20070119041531.GN3802@silverninja.net> References: <20070119041531.GN3802@silverninja.net> Message-ID: I concur. No harm in providing a utility cross platform main() wrapper, but no reason to enforce people to use it. On Jan 18, 2007, at 8:15 PM, Alex Norman wrote: > I'm not sure if I'm in the minority (it seems like I usually am) > but I don't see > why mint should abstract "main" or "winmain" or whatever your OS's > entry point > to apps is. That has nothing to do with multimedia. > > I DO agree that that can be a useful thing, but I really see this > as totally > separate from Mint and think that incorporating it in mint is bloat. > > I think this sort of thing would be good to make into a separate > library (a > crossplatform "main"), and could be used in Mint examples, but > should not be > part of the "core". This would be useful for a lot of other > applications that > are not mint related too. > > -Alex > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Thu Jan 18 23:21:33 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Thu Jan 18 23:23:53 2007 Subject: [Tdg] main Message-ID: <45B0717D.3020902@umail.ucsb.edu> I'm mostly concerned with what the novice user is required to do. It doesn't matter to me where the abstracted main code actually resides. It's ok with me if there is a seperate static linked library. The current build provides auxilary library headers that link in everything automatically. For example, when you say: #include "mint.h" Then the header automatically links in the graphics sub-system, audio sub-system, GLV sub-system, etc. I suppose it would be simple enough to have it link in the abstracted main as a seperate library also, along with all of these. Of course you can override this by saying: #include "mint-core.h" #include "mint-audio.h" This links just core and audio, with no abstracted main, no GLV, etc. In terms of header files, I really want to keep "mint.h" some that just gives the novice user everything they need. For someone who just wants to quickly prototype something why should they have to think about whether they linked in the right stuff to abstracting main or not.. Here is another question... Lets assume the user decides not to use our abstracted main. Does this mean they also don't use the abstracted OS event handler? Put simpler, if they write their own WinMain do they write their own WinProc too (translate to any other OS, I think the argument is the same)? WinProc is windows required user code that accepts windows-level event messages (WM_KEYDOWN) so the user app can handle them (it is a required callback from the Windows OS provided by the user). If we require the user to write WinMain and/or WinProc, then they will have to put all this extra code in to properly turn WM_KEYDOWN into a MINT KeyDownEvent. Otherwise it would be incompatible with our MINT event framework. Rama From lists at grahamwakefield.net Fri Jan 19 00:15:14 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Fri Jan 19 00:18:11 2007 Subject: [Tdg] abstracting main In-Reply-To: References: <20070119041531.GN3802@silverninja.net> Message-ID: <1186EC71-D225-4A53-8295-94463847F9A8@grahamwakefield.net> further to that, here's what they do in JUCE. They have a simple macro, just a few lines of code, that is entirely optional, but does make main.cpp cross platform. I think it is handy to have around, but we shouldn't make the library dependent upon using it, that's all. There's no need, when a singleton core object (which simply creates itself on first access) can achieve the same result as any LIBRARY_INIT() kind of call. #if defined (JUCE_GCC) || defined (__MWERKS__) #define START_JUCE_APPLICATION(AppClass) \ int main (int argc, char* argv[]) \ { \ return JUCEApplication::main (argc, argv, new AppClass()); \ } #elif JUCE_WIN32 #ifdef _CONSOLE #define START_JUCE_APPLICATION(AppClass) \ int main (int argc, char* argv[]) \ { \ return JUCEApplication::main (argc, argv, new AppClass ()); \ } #elif ! defined (_AFXDLL) #ifdef _WINDOWS_ #define START_JUCE_APPLICATION(AppClass) \ int WINAPI WinMain (HINSTANCE, HINSTANCE, LPSTR commandLine, int) \ { \ String commandLineString (commandLine); \ return JUCEApplication::main (commandLineString, new AppClass()); \ } #else #define START_JUCE_APPLICATION(AppClass) \ int __stdcall WinMain (int, int, const char* commandLine, int) \ { \ String commandLineString (commandLine); \ return JUCEApplication::main (commandLineString, new AppClass()); \ } #endif #endif #endif On Jan 18, 2007, at 10:24 PM, Graham Wakefield wrote: > I concur. > > No harm in providing a utility cross platform main() wrapper, but > no reason to enforce people to use it. > > On Jan 18, 2007, at 8:15 PM, Alex Norman wrote: > >> I'm not sure if I'm in the minority (it seems like I usually am) >> but I don't see >> why mint should abstract "main" or "winmain" or whatever your OS's >> entry point >> to apps is. That has nothing to do with multimedia. >> >> I DO agree that that can be a useful thing, but I really see this >> as totally >> separate from Mint and think that incorporating it in mint is bloat. >> >> I think this sort of thing would be good to make into a separate >> library (a >> crossplatform "main"), and could be used in Mint examples, but >> should not be >> part of the "core". This would be useful for a lot of other >> applications that >> are not mint related too. >> >> -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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20070119/e639dc31/attachment-0001.html From lists at grahamwakefield.net Fri Jan 19 00:18:53 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Fri Jan 19 00:21:44 2007 Subject: [Tdg] main In-Reply-To: <45B0717D.3020902@umail.ucsb.edu> References: <45B0717D.3020902@umail.ucsb.edu> Message-ID: <746782F5-4698-42DD-B5A7-8316BD1C93E4@grahamwakefield.net> > > Here is another question... Lets assume the user decides not to use > our abstracted main. Does this mean they also don't use the > abstracted OS event handler? Put simpler, if they write their own > WinMain do they write their own WinProc too (translate to any other > OS, I think the argument is the same)? WinProc is windows required > user code that accepts windows-level event messages (WM_KEYDOWN) so > the user app can handle them (it is a required callback from the > Windows OS provided by the user). If we require the user to write > WinMain and/or WinProc, then they will have to put all this extra > code in to properly turn WM_KEYDOWN into a MINT KeyDownEvent. > Otherwise it would be incompatible with our MINT event framework. Or they put Mint::WinProc(...); // whatever args WinProc takes Inside their own WinMain. From alex at neisis.net Fri Jan 19 08:07:09 2007 From: alex at neisis.net (Alex Norman) Date: Fri Jan 19 08:09:26 2007 Subject: [Tdg] Core Coding In-Reply-To: <45B0262A.1020204@umail.ucsb.edu> References: <45B0262A.1020204@umail.ucsb.edu> Message-ID: <20070119160709.GP3802@silverninja.net> Yes, well, we should first finally decide on the interface for these components first. > 3. Timer - We need a cross-platform, high performance timer. It should > provide the following functions, at minimum: > GetPerformanceTimer - Queries a high performance system timer on any > platform > GetSystemTime - Returns the system time. > We need to define what a time stamp is, but then it could be implemented. I'm into doing the timer, though I'll need help with the windoze part > > These really are very seperable pieces. Event Handler is not included > because the Event Handler is basically all these things combined, ie. it > is finished when the above is finished. The only final piece is to grab > Events from EventQueue and multiplex them to sub-systems. Again, this multiplexing, I think this is the user code, the top level user event handler, the user decides how to route events, it makes the system very powerful for the user and it simplifies the design. as far as not handling an event, this is really problematic because subsystems are scheduled, how do we pass an unhandled event back to be processed by another subsystem? (and when is it executed??) How are these events differentiated from new events? you could put some list inside the event to indicate the path of subsystems that didn't handle it (but I think that is unnecessarily complex). If the user does the "multiplexing" they can deal with these problems anyway they want... but "unhandled" or "rejected" event could be an event type itself. If the windowing sys doesn't handle a keypress then it pushes an event "unhandled" (that contains some pointer to the event that didn't handle it and some other indicator, like a pointer to the subsystem??? But I really don't see any of this being necessary if users do the event routing at the top level (the mint events, not the OS events that are then translated into mint events and put onto this top level event queue). Since they do it themselves they know what event types subsystems should accept and they can intercept/reroute/ignore events however they want (possibly dependent on state). -Alex From alex at neisis.net Fri Jan 19 08:21:28 2007 From: alex at neisis.net (Alex Norman) Date: Fri Jan 19 08:23:50 2007 Subject: [Tdg] main In-Reply-To: <746782F5-4698-42DD-B5A7-8316BD1C93E4@grahamwakefield.net> References: <45B0717D.3020902@umail.ucsb.edu> <746782F5-4698-42DD-B5A7-8316BD1C93E4@grahamwakefield.net> Message-ID: <20070119162128.GQ3802@silverninja.net> I think what Rama describes as the "mint" header should actually be the "mint-easy.h" header or something. A "power" user might have this: #include "mint.h" #include "mint/audio.h" #include "mint/graphics.h" WinProc(args){ //whatever code they want, perhaps intercepting some events and not passing //them on Mint::WinProc(args); } myeventhandler(queue, userdata){ do stuff with the queue } WinMain(args){ //or int main(argc, argv) on unix based systems //whatever code they want Mint::Application app; //app and Mint::Application are interchangeable //because this is a singleton class app.Init(Mint::Audio, Mint::Graphics); app.registerEventHandler(&myeventhandler); app.mainloop(); } ----------------- a user that really cares about the crossplatformness might use #include "mint.h" #include "mint/audio.h" #include "mint/graphics.h" #include "crossplatformentry.h" crossPlatformOSEventHandler(args){ //maybe do some stuff Mint::OSEventHandler(args); } crossPlatformMain(args){ //whatever code they want Mint::Application app; //app and Mint::Application are interchangeable //because this is a singleton class app.Init(Mint::Audio, Mint::Graphics); app.registerEventHandler(&myeventhandler); app.mainloop(); } ------------------------- the user that wants all the b.s. done for them might do #include "mint-easy.h" //all the above stuff would be done for them already, they just have to implement //the event handler. MintEventHandler(queue, userdata){ //process events } -Alex On 0, Graham Wakefield wrote: > > > >Here is another question... Lets assume the user decides not to use > >our abstracted main. Does this mean they also don't use the > >abstracted OS event handler? Put simpler, if they write their own > >WinMain do they write their own WinProc too (translate to any other > >OS, I think the argument is the same)? WinProc is windows required > >user code that accepts windows-level event messages (WM_KEYDOWN) so > >the user app can handle them (it is a required callback from the > >Windows OS provided by the user). If we require the user to write > >WinMain and/or WinProc, then they will have to put all this extra > >code in to properly turn WM_KEYDOWN into a MINT KeyDownEvent. > >Otherwise it would be incompatible with our MINT event framework. > > Or they put > > Mint::WinProc(...); // whatever args WinProc takes > > Inside their own WinMain. > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From lists at grahamwakefield.net Fri Jan 19 09:07:10 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Fri Jan 19 09:10:03 2007 Subject: [Tdg] Core Coding In-Reply-To: <20070119160709.GP3802@silverninja.net> References: <45B0262A.1020204@umail.ucsb.edu> <20070119160709.GP3802@silverninja.net> Message-ID: > >> >> These really are very seperable pieces. Event Handler is not included >> because the Event Handler is basically all these things combined, >> ie. it >> is finished when the above is finished. The only final piece is to >> grab >> Events from EventQueue and multiplex them to sub-systems. > > Again, this multiplexing, I think this is the user code, the top > level user > event handler, the user decides how to route events, it makes the > system very > powerful for the user and it simplifies the design. Yes, but the user also needs to be able to create new classes that can handle events, can be registered to each other, and send events to each other. My point was that the event handler / scheduler system needs to be independent of subsystems entirely. Subsystems make use of it, but so can user code. > > as far as not handling an event, this is really problematic because > subsystems > are scheduled, how do we pass an unhandled event back to be > processed by another > subsystem? (and when is it executed??) Using the return value of the handler callback, so it is executed immediately. The return value could be a bool, or int, or some other flag, or could event be the event * itself (return event to sender). Whatever. E.g. int myHandler(Event * e) { switch (e.type) case Keyboard: // do stuff break; default: return NOTHANDLED; } Not handling an event should not create a new event; there is no need. The event system that raised it should check the return value to see whether it should pass it to the next listener, or kill the event. From lists at grahamwakefield.net Fri Jan 19 09:08:25 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Fri Jan 19 09:12:08 2007 Subject: [Tdg] main In-Reply-To: <20070119162128.GQ3802@silverninja.net> References: <45B0717D.3020902@umail.ucsb.edu> <746782F5-4698-42DD-B5A7-8316BD1C93E4@grahamwakefield.net> <20070119162128.GQ3802@silverninja.net> Message-ID: <87638A67-3949-46A6-9DBF-8B0AC4399AD4@grahamwakefield.net> Great! On Jan 19, 2007, at 8:21 AM, Alex Norman wrote: > I think what Rama describes as the "mint" header should actually be > the > "mint-easy.h" header or something. > > A "power" user might have this: > > #include "mint.h" > #include "mint/audio.h" > #include "mint/graphics.h" > > WinProc(args){ > //whatever code they want, perhaps intercepting some events and > not passing > //them on > Mint::WinProc(args); > } > > myeventhandler(queue, userdata){ > do stuff with the queue > } > > WinMain(args){ //or int main(argc, argv) on unix based systems > //whatever code they want > Mint::Application app; //app and Mint::Application are > interchangeable > //because this is a singleton class > app.Init(Mint::Audio, Mint::Graphics); > app.registerEventHandler(&myeventhandler); > app.mainloop(); > } > > ----------------- > a user that really cares about the crossplatformness might use > > #include "mint.h" > #include "mint/audio.h" > #include "mint/graphics.h" > #include "crossplatformentry.h" > > crossPlatformOSEventHandler(args){ > //maybe do some stuff > Mint::OSEventHandler(args); > } > > crossPlatformMain(args){ > //whatever code they want > Mint::Application app; //app and Mint::Application are > interchangeable > //because this is a singleton class > app.Init(Mint::Audio, Mint::Graphics); > app.registerEventHandler(&myeventhandler); > app.mainloop(); > } > > ------------------------- > the user that wants all the b.s. done for them might do > > #include "mint-easy.h" > > //all the above stuff would be done for them already, they just > have to implement > //the event handler. > > MintEventHandler(queue, userdata){ > //process events > } > > > -Alex > > On 0, Graham Wakefield wrote: >>> >>> Here is another question... Lets assume the user decides not to use >>> our abstracted main. Does this mean they also don't use the >>> abstracted OS event handler? Put simpler, if they write their own >>> WinMain do they write their own WinProc too (translate to any other >>> OS, I think the argument is the same)? WinProc is windows required >>> user code that accepts windows-level event messages (WM_KEYDOWN) so >>> the user app can handle them (it is a required callback from the >>> Windows OS provided by the user). If we require the user to write >>> WinMain and/or WinProc, then they will have to put all this extra >>> code in to properly turn WM_KEYDOWN into a MINT KeyDownEvent. >>> Otherwise it would be incompatible with our MINT event framework. >> >> Or they put >> >> Mint::WinProc(...); // whatever args WinProc takes >> >> Inside their own WinMain. >> >> _______________________________________________ >> 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 lists at grahamwakefield.net Fri Jan 19 09:09:15 2007 From: lists at grahamwakefield.net (Graham Wakefield) Date: Fri Jan 19 09:12:43 2007 Subject: [Tdg] main In-Reply-To: <20070119162128.GQ3802@silverninja.net> References: <45B0717D.3020902@umail.ucsb.edu> <746782F5-4698-42DD-B5A7-8316BD1C93E4@grahamwakefield.net> <20070119162128.GQ3802@silverninja.net> Message-ID: Great! On Jan 19, 2007, at 8:21 AM, Alex Norman wrote: > I think what Rama describes as the "mint" header should actually be > the > "mint-easy.h" header or something. > > A "power" user might have this: > > #include "mint.h" > #include "mint/audio.h" > #include "mint/graphics.h" > > WinProc(args){ > //whatever code they want, perhaps intercepting some events and > not passing > //them on > Mint::WinProc(args); > } > > myeventhandler(queue, userdata){ > do stuff with the queue > } > > WinMain(args){ //or int main(argc, argv) on unix based systems > //whatever code they want > Mint::Application app; //app and Mint::Application are > interchangeable > //because this is a singleton class > app.Init(Mint::Audio, Mint::Graphics); > app.registerEventHandler(&myeventhandler); > app.mainloop(); > } > > ----------------- > a user that really cares about the crossplatformness might use > > #include "mint.h" > #include "mint/audio.h" > #include "mint/graphics.h" > #include "crossplatformentry.h" > > crossPlatformOSEventHandler(args){ > //maybe do some stuff > Mint::OSEventHandler(args); > } > > crossPlatformMain(args){ > //whatever code they want > Mint::Application app; //app and Mint::Application are > interchangeable > //because this is a singleton class > app.Init(Mint::Audio, Mint::Graphics); > app.registerEventHandler(&myeventhandler); > app.mainloop(); > } > > ------------------------- > the user that wants all the b.s. done for them might do > > #include "mint-easy.h" > > //all the above stuff would be done for them already, they just > have to implement > //the event handler. > > MintEventHandler(queue, userdata){ > //process events > } > > > -Alex > > On 0, Graham Wakefield wrote: >>> >>> Here is another question... Lets assume the user decides not to use >>> our abstracted main. Does this mean they also don't use the >>> abstracted OS event handler? Put simpler, if they write their own >>> WinMain do they write their own WinProc too (translate to any other >>> OS, I think the argument is the same)? WinProc is windows required >>> user code that accepts windows-level event messages (WM_KEYDOWN) so >>> the user app can handle them (it is a required callback from the >>> Windows OS provided by the user). If we require the user to write >>> WinMain and/or WinProc, then they will have to put all this extra >>> code in to properly turn WM_KEYDOWN into a MINT KeyDownEvent. >>> Otherwise it would be incompatible with our MINT event framework. >> >> Or they put >> >> Mint::WinProc(...); // whatever args WinProc takes >> >> Inside their own WinMain. >> >> _______________________________________________ >> 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 Fri Jan 19 09:34:47 2007 From: alex at neisis.net (Alex Norman) Date: Fri Jan 19 09:37:04 2007 Subject: [Tdg] Core Coding In-Reply-To: References: <45B0262A.1020204@umail.ucsb.edu> <20070119160709.GP3802@silverninja.net> Message-ID: <20070119173447.GR3802@silverninja.net> see below > > > >as far as not handling an event, this is really problematic because > >subsystems > >are scheduled, how do we pass an unhandled event back to be > >processed by another > >subsystem? (and when is it executed??) > > Using the return value of the handler callback, so it is executed > immediately. > > The return value could be a bool, or int, or some other flag, or > could event be the event * itself (return event to sender). Whatever. > > E.g. > > int myHandler(Event * e) > { > switch (e.type) > case Keyboard: > // do stuff > break; > default: > return NOTHANDLED; > } > I don't understand how this could work. In my understanding of the system, a subsystem has a queue that has events pushed to it. The subsystem is scheduled somehow, after the event is pushed onto the queue, (by a hardware audio callback, or by our system), and then it reacts to things on its queue (in a loop, consuming the items in the queue), so there is no way to "return" this code. ie: void myHandler(EventQueue * q){ while(!q.empty()){ e = q->dequeue(); if(some condition){ //do something } else if(something else){ Mint::EnqueueEvent(new BlahEvent(args)); } } } But I actually think of this handler as being a method of a subsystem. We could create a subclass of the this type of subsystem that might provide this "user callback" if we want... Also, if a user writes handlers, why would they pass events to these handlers that they cannot handle? I think we need a graphical representation for how the system works, and what owns what. I'll do mine right idea right now and post it when I have it done. -Alex From ljputnam at umail.ucsb.edu Fri Jan 19 09:41:28 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Fri Jan 19 09:44:00 2007 Subject: [Tdg] abstracting main In-Reply-To: <45B047E7.6010609@umail.ucsb.edu> References: <20070119041531.GN3802@silverninja.net> <45B047E7.6010609@umail.ucsb.edu> Message-ID: <20070119094128.69g91j8c0s4wkg4k@webaccess.umail.ucsb.edu> The BIG question is is it char ** argv or char * argv[]? Lance Rama Hoetzlein wrote: > What's the problem with the BUILD_OSMAIN solution we did? > > It would let you write the OS main that you want, and basically turn > off all that abstraction. > > I think a lot of people, especially beginners, are going to want this. > I'd like my apps (stuff I create with MINT) to compile on different > platforms without having to provide a different main for each. > > Rama > > Alex Norman wrote: > >> I'm not sure if I'm in the minority (it seems like I usually am) >> but I don't see >> why mint should abstract "main" or "winmain" or whatever your OS's >> entry point >> to apps is. That has nothing to do with multimedia. >> >> I DO agree that that can be a useful thing, but I really see this as totally >> separate from Mint and think that incorporating it in mint is >> bloat. I think this sort of thing would be good to make into a >> separate library (a >> crossplatform "main"), and could be used in Mint examples, but should not be >> part of the "core". This would be useful for a lot of other >> applications that >> are not mint related too. >> >> -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 -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From ljputnam at umail.ucsb.edu Fri Jan 19 09:49:46 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Fri Jan 19 09:52:16 2007 Subject: [Tdg] abstracting main In-Reply-To: <20070119094128.69g91j8c0s4wkg4k@webaccess.umail.ucsb.edu> References: <20070119041531.GN3802@silverninja.net> <45B047E7.6010609@umail.ucsb.edu> <20070119094128.69g91j8c0s4wkg4k@webaccess.umail.ucsb.edu> Message-ID: <20070119094946.bo0omiqw00sg88oo@webaccess.umail.ucsb.edu> But, seriously, I think there is too much focus on making Mint easy to use rather than just making it work. I think the design and 'making it work' phase need to start mingling at this point... Lance "Lance J. Putnam" wrote: > The BIG question is is it char ** argv or char * argv[]? > > Lance > > Rama Hoetzlein wrote: > >> What's the problem with the BUILD_OSMAIN solution we did? >> >> It would let you write the OS main that you want, and basically turn >> off all that abstraction. >> >> I think a lot of people, especially beginners, are going to want this. >> I'd like my apps (stuff I create with MINT) to compile on different >> platforms without having to provide a different main for each. >> >> Rama >> >> Alex Norman wrote: >> >>> I'm not sure if I'm in the minority (it seems like I usually am) >>> but I don't see >>> why mint should abstract "main" or "winmain" or whatever your OS's >>> entry point >>> to apps is. That has nothing to do with multimedia. >>> >>> I DO agree that that can be a useful thing, but I really see this >>> as totally >>> separate from Mint and think that incorporating it in mint is >>> bloat. I think this sort of thing would be good to make into a >>> separate library (a >>> crossplatform "main"), and could be used in Mint examples, but >>> should not be >>> part of the "core". This would be useful for a lot of other >>> applications that >>> are not mint related too. >>> >>> -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 > > > > -- > 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 alex at neisis.net Fri Jan 19 11:07:47 2007 From: alex at neisis.net (Alex Norman) Date: Fri Jan 19 11:10:07 2007 Subject: [Tdg] my image of "my" design for mint Message-ID: <20070119190747.GS3802@silverninja.net> http://neisis.net/~alex/drop/mint-alex.png some basic class headers are here plus a really basic example "application" that uses this library: http://neisis.net/~alex/drop/alex-mint-code/ -Alex From jcastellanos at umail.ucsb.edu Fri Jan 19 11:29:22 2007 From: jcastellanos at umail.ucsb.edu (Jorge Castellanos) Date: Fri Jan 19 11:32:01 2007 Subject: [Tdg] remained unsolved... Message-ID: <3C107D47-A071-4EFE-909E-E0CDF79858E9@umail.ucsb.edu> I started collecting the Coding Style preferences sent last month, but soon realized that nothing was agreed upon. Here is a list of what has been proposed, and some more.... If we all agree on something, I can put it on the wiki. Class Name: Starts with Caps + "Camel Case" Example: ClassName Class Members: Prefix m + "Camel Case" (the other suggestion - by Rama - was to prefix variables with their type. Example: mVariableName Constants: Prefix k + "Camel Case" Example: kTheConstant Static Variables: Prefix s + "Camel Case" Example: kSomeStaticVariable Remained open... For name clashes... Namespace MINT (?) or Prefix class names (?) Setters, Getters.... "setSomething(value); & value something();" in this case, if it returns a bool, then the getter becomes "isSomething ()" (?), or "setSomething(value); & value getSomething();" Comments ??? Are we using Doxygen ??? Other suggestions: Arrays (or Collections) should finish with "s". This implies that it holds many items. Pointers to any object should finish with "Ptr" or something like that. This way it's always clear when dealing with a pointer as opposed to an actual object. In a class, "public:" data should be listed first, followed by "protected:" and then by "private:". This way when reading a header file to see its interface you don't have read first the private. In other words, the interface is presented first. "#define" s should be capitalized always. "default" values should go in the header file. (I don't have a strong preference here, but they have to go somewhere). Am I missing someting? We can also add to it as coding progresses. j From alex at neisis.net Fri Jan 19 15:24:56 2007 From: alex at neisis.net (Alex Norman) Date: Fri Jan 19 15:25:04 2007 Subject: [Tdg] Re: my image of "my" design for mint In-Reply-To: <45B1436E.7070904@umail.ucsb.edu> References: <45B1436E.7070904@umail.ucsb.edu> Message-ID: <20070119232456.GV3802@silverninja.net> the wiki link http://tdg.mat.ucsb.edu/index.php/Design_Diagram_%28proposed_by_Alex%29 -Alex On 0, Rama Hoetzlein wrote: > Alex, could you post this on the wiki maybe? > > Rama > > Alex Norman wrote: > > >http://neisis.net/~alex/drop/mint-alex.png > > > >some basic class headers are here plus a really basic example > >"application" that > >uses this library: > >http://neisis.net/~alex/drop/alex-mint-code/ > > > >-Alex > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > From wakefield at mat.ucsb.edu Fri Jan 19 15:39:03 2007 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Fri Jan 19 15:39:10 2007 Subject: [Tdg] my image of "my" design for mint In-Reply-To: <20070119190747.GS3802@silverninja.net> References: <20070119190747.GS3802@silverninja.net> Message-ID: <426CCA6C-E056-41D0-AF88-E69A907D93D7@mat.ucsb.edu> Looks great! I guess the fundamental difference is that I imagine users registering many event handlers, for different logical components of the application, rather than a single core global event handler. I suppose MINT could easily support both approaches, but for the latter, the eventHandler class and eventHandlerCallback class should be available for the user to subclass and use. G On Jan 19, 2007, at 11:07 AM, Alex Norman wrote: > http://neisis.net/~alex/drop/mint-alex.png > > some basic class headers are here plus a really basic example > "application" that > uses this library: > http://neisis.net/~alex/drop/alex-mint-code/ > > -Alex > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Fri Jan 19 15:54:57 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Fri Jan 19 15:55:01 2007 Subject: [Tdg] my image of "my" design for mint In-Reply-To: <426CCA6C-E056-41D0-AF88-E69A907D93D7@mat.ucsb.edu> References: <20070119190747.GS3802@silverninja.net> <426CCA6C-E056-41D0-AF88-E69A907D93D7@mat.ucsb.edu> Message-ID: <45B15A51.8080307@umail.ucsb.edu> Graham Wakefield wrote: > Looks great! I don't see any need to subclass Subsystem as ThreadedSubsystem and NonThreadedSubsystem. I think this can be determined entirely by the behavior of the Subsystem. Can you tell me why the core needs to know about this? It seams the threaded-nonthreaded issue is entirely built into our design of how events are handled. > I guess the fundamental difference is that I imagine users > registering many event handlers, for different logical components of > the application, rather than a single core global event handler. I > suppose MINT could easily support both approaches, but for the > latter, the eventHandler class and eventHandlerCallback class should > be available for the user to subclass and use. Thats what my current code-base does. You can register any number of event handlers. R > > G > > > On Jan 19, 2007, at 11:07 AM, Alex Norman wrote: > >> http://neisis.net/~alex/drop/mint-alex.png >> >> some basic class headers are here plus a really basic example >> "application" that >> uses this library: >> http://neisis.net/~alex/drop/alex-mint-code/ >> >> -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 alex at neisis.net Fri Jan 19 17:27:11 2007 From: alex at neisis.net (Alex Norman) Date: Fri Jan 19 17:27:19 2007 Subject: [Tdg] my image of "my" design for mint In-Reply-To: <45B15A51.8080307@umail.ucsb.edu> References: <20070119190747.GS3802@silverninja.net> <426CCA6C-E056-41D0-AF88-E69A907D93D7@mat.ucsb.edu> <45B15A51.8080307@umail.ucsb.edu> Message-ID: <20070120012711.GW3802@silverninja.net> On 0, Rama Hoetzlein wrote: > Graham Wakefield wrote: > > >Looks great! > > I don't see any need to subclass Subsystem as ThreadedSubsystem and > NonThreadedSubsystem. I think this can be determined entirely by the > behavior of the Subsystem. Can you tell me why the core needs to know > about this? It seams the threaded-nonthreaded issue is entirely built > into our design of how events are handled. > The reason I did this is because I image this would help us not accidentally put threaded subsystems into the core's scheduling queue.... I don't know if that is a feature we want to have or not... but that is my reasoning.. should users be allowed to schedule things that are already being handled by a thread? > >I guess the fundamental difference is that I imagine users > >registering many event handlers, for different logical components of > >the application, rather than a single core global event handler. I > >suppose MINT could easily support both approaches, but for the > >latter, the eventHandler class and eventHandlerCallback class should > >be available for the user to subclass and use. > > Thats what my current code-base does. You can register any number of > event handlers. > My design allows for this too.. you just implement a subsystem (or use a generic subsystem that has a callback if we decide to provide that), a subsystem is essentially an event handler that is possibly scheduled, but on the top level there is one event handler that handles ALL events in the core's queue.. and then the user can do whatever they want with these. -Alex > R > > > > >G > > > > > >On Jan 19, 2007, at 11:07 AM, Alex Norman wrote: > > > >>http://neisis.net/~alex/drop/mint-alex.png > >> > >>some basic class headers are here plus a really basic example > >>"application" that > >>uses this library: > >>http://neisis.net/~alex/drop/alex-mint-code/ > >> > >>-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 rch at umail.ucsb.edu Fri Jan 19 17:39:24 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Fri Jan 19 17:39:28 2007 Subject: [Tdg] my image of "my" design for mint In-Reply-To: <20070120012711.GW3802@silverninja.net> References: <20070119190747.GS3802@silverninja.net> <426CCA6C-E056-41D0-AF88-E69A907D93D7@mat.ucsb.edu> <45B15A51.8080307@umail.ucsb.edu> <20070120012711.GW3802@silverninja.net> Message-ID: <45B172CC.5020505@umail.ucsb.edu> >>Thats what my current code-base does. You can register any number of >>event handlers. >> >My design allows for this too.. you just implement a subsystem (or use a generic >subsystem that has a callback if we decide to provide that), a subsystem is >essentially an event handler that is possibly scheduled, but on the top level >there is one event handler that handles ALL events in the core's queue.. and >then the user can do whatever they want with these. > > I meant that any subsytem could register any number of event handlers, without adding another subsystem. The user code could also register any number of event handlers.. An event handling process is not tied to a subsystem. R From rch at umail.ucsb.edu Fri Jan 19 17:53:33 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Fri Jan 19 17:53:36 2007 Subject: [Tdg] clarification Message-ID: <45B1761D.10106@umail.ucsb.edu> Maybe I should clarify. What I have so far is: - There are any number of eventCallbacks (like userEventCallback, soundCallback) - There are also any number of processCallback (like run, draw, etc.) - These are both processes, with timing control, but there can by any number of them per sub-system - The user code can also register any number of process or event callbacks. - There is only one core event handler that demultiplexes events to various sub-systems. - Sub-systems can register any number of event callbacks or processes - So i mean: One core event handler (does demultiplexing to sub-systems) Multiple sub-systems Many event callbacks (possible more than there are sub-systems) Many processes (treated in code the same way as event callbacks) (A process is just a callback that doesn't take events, like run and draw) R From alex at neisis.net Fri Jan 19 19:11:28 2007 From: alex at neisis.net (Alex Norman) Date: Fri Jan 19 19:11:35 2007 Subject: [Tdg] clarification In-Reply-To: <45B1761D.10106@umail.ucsb.edu> References: <45B1761D.10106@umail.ucsb.edu> Message-ID: <20070120031128.GX3802@silverninja.net> Could you provide a graphical diagram of your system? -Alex On 0, Rama Hoetzlein wrote: > Maybe I should clarify. What I have so far is: > > - There are any number of eventCallbacks (like userEventCallback, > soundCallback) > - There are also any number of processCallback (like run, draw, etc.) > - These are both processes, with timing control, but there can by any > number of them per sub-system > - The user code can also register any number of process or event callbacks. > - There is only one core event handler that demultiplexes events to > various sub-systems. > - Sub-systems can register any number of event callbacks or processes > - So i mean: > One core event handler (does demultiplexing to sub-systems) > Multiple sub-systems > Many event callbacks (possible more than there are sub-systems) > Many processes (treated in code the same way as event callbacks) > > (A process is just a callback that doesn't take events, like run and draw) > > R > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Fri Jan 19 23:43:43 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Fri Jan 19 23:43:50 2007 Subject: [Tdg] Question.. Message-ID: <45B1C82F.8040209@umail.ucsb.edu> Question... In Carbon or in X, if you create two windows, then when you get an OS keyboard event how does the OS tell you which window received it?.. Do all events for both windows come into one callback function? Or do you have to specify a new callback for each window you create? (Just to get it right, we are using X for Linux and Carbon for Mac, right?) Rama From wakefield at mat.ucsb.edu Sat Jan 20 00:53:39 2007 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Sat Jan 20 00:53:53 2007 Subject: [Tdg] Question.. In-Reply-To: <45B1C82F.8040209@umail.ucsb.edu> References: <45B1C82F.8040209@umail.ucsb.edu> Message-ID: <55B4FE7C-3988-463E-BB84-5FE123E1EFD3@mat.ucsb.edu> 1. You call a carbon method to get the window context from the event object. You can separately register callbacks per window, or just register a global callback for the application. You can choose which callbacks receive keyboard events by setting flags in the constructor. So, pretty flexible. 2. Probably Carbon on Mac, or possibly Cocoa. The approach is mostly the same for both (they share most of the same underlying code), but the interface/API/language is different. Carbon is C, Cocoa is Objective-C. Both can be easily embedded in C++ (though Objective-C is slightly more complex). On Jan 19, 2007, at 11:43 PM, Rama Hoetzlein wrote: > Question... In Carbon or in X, if you create two windows, then when > you get an OS keyboard event how does the OS tell you which window > received it?.. Do all events for both windows come into one > callback function? Or do you have to specify a new callback for > each window you create? > > (Just to get it right, we are using X for Linux and Carbon for Mac, > right?) > > Rama > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Mon Jan 29 19:32:01 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Mon Jan 29 19:32:12 2007 Subject: [Tdg] Update Message-ID: <45BEBC31.8010103@umail.ucsb.edu> TDGers, Update for those who want to keep informed.. Last week the group made several design decisions that put us on a good track to starting implementing. I will be working up new design drawings and the code base for our first subversion commit. This should allow us to post clear definitions of what code needs to be written soon. In the meantime, we've decided on a shift of focus for meetings over the next two weeks as we prepare for the Feb 9th presentation of Mint.. Hope to see you in the meetings. Rama From wakefield at mat.ucsb.edu Tue Jan 30 14:39:10 2007 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Tue Jan 30 14:39:18 2007 Subject: [Tdg] sonification Message-ID: <13199A43-933E-489B-8399-2F1A00B8C0C2@mat.ucsb.edu> http://en.wikipedia.org/wiki/Sonification -- organizations -- http://www.icad.org/ http://sonification.de/ -- state of the art -- http://www.icad.org/websiteV2.0/References/nsf.html http://www.interactive-sonification.org/ -- software -- http://www.sonenvir.at/ From wesley.hoke at gmail.com Wed Jan 31 09:08:30 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Jan 31 09:08:43 2007 Subject: [Tdg] Presentation Stuff Message-ID: <1079b050701310908n5d65af00v5bd8b42be3b9a47c@mail.gmail.com> Hi everyone, Could we compile on email the ideas we'd like to present on the 9th? Here's what I remember from yesterday... Current software doesn't address out needs: +Scientific visualization software doesn't handle audio (or consider any kind of multi-modal presentation) +Software like Processing/Max don't deal well with data crunching needed to process scientific data, don't scale well to the size of the systems scientific data is presented on (multimonitor displays, allosphere, ...) Software and research: +Need software that is flexible enough to support a multitude of approaches to handling data +Need software that can be easily extended to incorporate new research without incurring a huge time and labor cost +Has a low cost and straightforward path to moving from research development of the software to production (shouldn't have to rewrite completely to make production ready) Collaboration +Want to work with other groups to develop use cases so that we have specifics to target as we design Mint, keeping Mint grounded in practicality and making it more immediately useful to the community Mint is targetting Licensing +LGPL: open source for didactic reasons as well as encouraging adoption by others From alex at neisis.net Wed Jan 31 10:09:12 2007 From: alex at neisis.net (Alex Norman) Date: Wed Jan 31 10:09:23 2007 Subject: [Tdg] Presentation Stuff In-Reply-To: <1079b050701310908n5d65af00v5bd8b42be3b9a47c@mail.gmail.com> References: <1079b050701310908n5d65af00v5bd8b42be3b9a47c@mail.gmail.com> Message-ID: <20070131180912.GF4138@silverninja.net> Btw, it turns out I will not be able to be at the presentation because of UCdarNet. Rama wrote a list of things, one of the things that we discussed was that we don't really want to get into a licensing debate. Basically, we should say that it will be free open source software and not mention LGPL because we don't want to have to explain it or have a debate over the pros/cons of it. There are a couple other things that we really want to steer clear of [i say we meaning the group, even though I won't be there]. Another one of these is the effectiveness of the allosphere for scientific research. We don't want to go into details of the software, just provide a high level description of what it will do, how it fills gaps that need to be filled, how it is and how it benefits research... -Alex On 0, Wesley Smith wrote: > Hi everyone, > Could we compile on email the ideas we'd like to present on the 9th? > Here's what I remember from yesterday... > > > Current software doesn't address out needs: > +Scientific visualization software doesn't handle audio (or > consider any kind of multi-modal presentation) > +Software like Processing/Max don't deal well with data crunching > needed to process scientific data, don't scale well to the size of the > systems scientific data is presented on (multimonitor displays, > allosphere, ...) > > Software and research: > +Need software that is flexible enough to support a multitude of > approaches to handling data > +Need software that can be easily extended to incorporate new > research without incurring a huge time and labor cost > +Has a low cost and straightforward path to moving from research > development of the software to production (shouldn't have to rewrite > completely to make production ready) > > Collaboration > +Want to work with other groups to develop use cases so that we > have specifics to target as we design Mint, keeping Mint grounded in > practicality and making it more immediately useful to the community > Mint is targetting > > Licensing > +LGPL: open source for didactic reasons as well as encouraging > adoption by others > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Wed Jan 31 13:53:05 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Wed Jan 31 13:53:16 2007 Subject: [Tdg] Presentation Stuff In-Reply-To: <20070131180912.GF4138@silverninja.net> References: <1079b050701310908n5d65af00v5bd8b42be3b9a47c@mail.gmail.com> <20070131180912.GF4138@silverninja.net> Message-ID: <45C10FC1.80002@umail.ucsb.edu> Other things on that "piece of paper" (notes from meeting): + Goals and Vision: Why.. Platform for research to connect multiple disciplines. Meta-tool that covers Processing, Max/Jitter, VisBio, C/C++, Java, NanoCad, etc. Possibly show a table of different systems but then focus on our goal of transcending them.. Simple slides are better (with images). There will be plent to talk about. + Structure - what is it? Picture of our circle diagram with inside / outside of Mint. + Extensibility - Can add any number of tools to core. (This is because our Event Handling is very high-level and generic). Solve several problems in one place. Not just for scientific visualization. + How is it possible we can make such a high-level tool in so short a time? a. 8 months of working together already b. Consistent group goal c. Using already built components (GameX, GLV) d. Background of members corresponds to sub-systems e. Leveraging other open-source projects + Possibly include a slide of Mint + Chrominum - or some other system showing that Mint is a meta-system that others can plug into. Mint lets you plug together many different systems. + Possibly include an abstract slide of Mint event handling. How Mint enables multiple sub-system, even those from other disciplines, to plug into a single unified core. This is due to our high-level event passing system. + Scientific Visualization example - Graham and I discussed the possible need for a clear example that demonstrates what we mean by enabling sci. viz. (This is not about going into allosphere as research tool, but justifing our tool as something that enables/speeds-up sci. viz. research). One example might be geography, where the scientist does not wish to spend lots of time getting zoomable / pannable maps on screen - but can have Mint do that and simply overlay their data on top. + Technical slide - Just one slide of our code design. Don't go into algorithms or how it works. Just say "a lot of design work is already done". To demonstrate what we have already accomplished. + Regarding Allosphere - Say what we want to do. Be sure to include a clear distinction between our tool as a platform to enable the allosphere (an example of what Mint can do), and what we will not focus on. Mint is not a tool to solve specific technical problems related to allosphere. + Collaboration - We would like to open discussion with other groups. Will create an online list of potential applications that Mint could be applied to. Another list will be created to solicit design ideas and feature suggestions... We are also open to others working with us who might like to help develop Mint - this need not be limited to core sub-systems (e.g. networking), as they could help develop subsystems for other disciplines: computer vision, plugging in sci. math, etc. + Sub-system Examples: Could include slides on audio, GLV, and/or rendering + Application Examples: Could include slides on allosphere, scientific visualization, and digital media + Past Igert Examples: Could include a slide of a past Igert project and how it would have benefited from Mint. Specifically break down an Igert project (perhaps by talking to that group) into general task areas and show where Mint would have greatly improved dev. time.. Note: I think it would be great to breakdown the first Spheres of Influence (I) project. Why? 1) Because its been superscened by SOI II (so no one will feel their toes are being stepped on), 2) Because its developers are still around, so we can analyze its challenges and task areas in retrospect + Licensing: As mentioned by Alex. Don't go into details. Just say license we've selected serves our goals - open research. Alex Norman wrote: >Btw, it turns out I will not be able to be at the presentation because of >UCdarNet. > >Rama wrote a list of things, one of the things that we discussed was that we >don't really want to get into a licensing debate. Basically, we should say that >it will be free open source software and not mention LGPL because we don't want >to have to explain it or have a debate over the pros/cons of it. > >There are a couple other things that we really want to steer clear of [i say we >meaning the group, even though I won't be there]. Another one of these is the >effectiveness of the allosphere for scientific research. We don't want to go >into details of the software, just provide a high level description of what it >will do, how it fills gaps that need to be filled, how it is and how it benefits >research... > >-Alex > >On 0, Wesley Smith wrote: > > >>Hi everyone, >>Could we compile on email the ideas we'd like to present on the 9th? >>Here's what I remember from yesterday... >> >> >>Current software doesn't address out needs: >> +Scientific visualization software doesn't handle audio (or >>consider any kind of multi-modal presentation) >> +Software like Processing/Max don't deal well with data crunching >>needed to process scientific data, don't scale well to the size of the >>systems scientific data is presented on (multimonitor displays, >>allosphere, ...) >> >>Software and research: >> +Need software that is flexible enough to support a multitude of >>approaches to handling data >> +Need software that can be easily extended to incorporate new >>research without incurring a huge time and labor cost >> +Has a low cost and straightforward path to moving from research >>development of the software to production (shouldn't have to rewrite >>completely to make production ready) >> >>Collaboration >> +Want to work with other groups to develop use cases so that we >>have specifics to target as we design Mint, keeping Mint grounded in >>practicality and making it more immediately useful to the community >>Mint is targetting >> >>Licensing >> +LGPL: open source for didactic reasons as well as encouraging >>adoption by others >>_______________________________________________ >>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 ljputnam at umail.ucsb.edu Wed Jan 31 14:18:57 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Wed Jan 31 14:19:09 2007 Subject: [Tdg] Presentation Stuff In-Reply-To: <45C10FC1.80002@umail.ucsb.edu> References: <1079b050701310908n5d65af00v5bd8b42be3b9a47c@mail.gmail.com> <20070131180912.GF4138@silverninja.net> <45C10FC1.80002@umail.ucsb.edu> Message-ID: <20070131141857.afp86qccg0sw4g4s@webaccess.umail.ucsb.edu> Rama Hoetzlein wrote: > + Scientific Visualization example - Graham and I discussed the > possible need for a clear example that demonstrates what we mean by > enabling sci. viz. (This is not about going into allosphere as research > tool, but justifing our tool as something that enables/speeds-up sci. > viz. research). One example might be geography, where the scientist > does not wish to spend lots of time getting zoomable / pannable maps on > screen - but can have Mint do that and simply overlay their data on top. > I would prefer to steer clear of the term "Scientific Visualization" as it tends to imply a single modality. How about "Scientific Simulation/Representation"? We could even talk about the AlloBrain project here and show images/videos from it. 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 Wed Jan 31 14:29:33 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Wed Jan 31 14:29:50 2007 Subject: [Tdg] Presentation Stuff In-Reply-To: <20070131141857.afp86qccg0sw4g4s@webaccess.umail.ucsb.edu> References: <1079b050701310908n5d65af00v5bd8b42be3b9a47c@mail.gmail.com> <20070131180912.GF4138@silverninja.net> <45C10FC1.80002@umail.ucsb.edu> <20070131141857.afp86qccg0sw4g4s@webaccess.umail.ucsb.edu> Message-ID: <45C1184D.7020103@umail.ucsb.edu> > I would prefer to steer clear of the term "Scientific Visualization" > as it tends to imply a single modality. How about "Scientific > Simulation/Representation"? We could even talk about the AlloBrain > project here and show images/videos from it. Not necessarily. Scientific Visualiation is a very broad field, with connections to visual and information design as well as science. Would you steer clear of "Media Art" as well? That also implies a single modality (an artistic one). I don't see any problem with using the terms. Just making it very clear it is one modality among all of those we are addressing. R From ljputnam at umail.ucsb.edu Wed Jan 31 14:58:20 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Wed Jan 31 14:58:31 2007 Subject: [Tdg] Presentation Stuff In-Reply-To: <45C1184D.7020103@umail.ucsb.edu> References: <1079b050701310908n5d65af00v5bd8b42be3b9a47c@mail.gmail.com> <20070131180912.GF4138@silverninja.net> <45C10FC1.80002@umail.ucsb.edu> <20070131141857.afp86qccg0sw4g4s@webaccess.umail.ucsb.edu> <45C1184D.7020103@umail.ucsb.edu> Message-ID: <20070131145820.qiz28nsr48googos@webaccess.umail.ucsb.edu> Rama Hoetzlein wrote: > >> I would prefer to steer clear of the term "Scientific >> Visualization" as it tends to imply a single modality. How about >> "Scientific Simulation/Representation"? We could even talk about >> the AlloBrain project here and show images/videos from it. > > Not necessarily. Scientific Visualiation is a very broad field, with > connections to visual and information design as well as science. Would > you steer clear of "Media Art" as well? That also implies a single > modality (an artistic one). I don't see any problem with using the > terms. Just making it very clear it is one modality among all of those > we are addressing. > Sorry, I wasn't clear about what I meant by modality. I meant modality as one of our 5 senses, not a methodology (science, art, design, etc.). My point was, I don't know why you want to talk about something that is only including the visual aspects of information representation. There are alrerady hundreds of applications out there for doing this stuff. How is our research novel then? We have implemented a project that is multimodal (vision, sound, human interfaces), the brain project, and I think it would be a stronger example of what our system can be used for and how it enables a form of data representation that most existing packages weren't designed for. 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 Wed Jan 31 15:42:27 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Wed Jan 31 15:42:35 2007 Subject: [Tdg] Presentation stuff Message-ID: <45C12963.6050902@umail.ucsb.edu> I see your point about modality. I agree that our examples should be cross modal (in the senses sense). However, while there are hundreds of applications for visualization, there are also many ways one might do novel visual research in these areas - i'm just saying there is still novel research to be done visually. Despite this, I completely agree we should focus on both visual and aural modalities. Really, this is up to you guys to provide examples. I don't know this field so well so you'll have to fill in some examples for me. I think if we work together we could create a good example that would be novel in both aspects: Scientific Sonification + Visualization.. alternatively, we could seperate our examples. Its up to us. On another note, personally I think we should steer clear of the AlloBrain as a scientific example because, 1) its not science, and 2) its too centered around the allosphere. Perhaps we can come up with another example that is both novel visual + aural research. Rama From wesley.hoke at gmail.com Wed Jan 31 16:16:08 2007 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed Jan 31 16:16:16 2007 Subject: [Tdg] Meeting with the Big Men Message-ID: <1079b050701311616i36175460ne4b71feb8107971d@mail.gmail.com> Hi everyone, I just had a meeting with Manjunath, Turk, and Legrady. Some interesting points came up. Basically, George and Turk expressed "surprise" at being the PIs on Mint. They suggested that we should find more appropriate people such as Pope, Tobias, and Xavier (even if he's only going to be here for a few more months). They said we should make sure to get such people to our presentation so that they can see the project and potentially advise us. We need to interact with the faculty more about the project. We also need to say why it's research and not just "development" and where we could publish. We need to say in our presentation what kind of product or demo we could have by when. I think all of you will have the same kind of meeting in the near future, so be prepared to discuss this kind of stuff. Tommorrow we should go through some of this business. wes From ljputnam at umail.ucsb.edu Wed Jan 31 22:41:17 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Wed Jan 31 22:41:29 2007 Subject: [Tdg] Presentation stuff In-Reply-To: <45C12963.6050902@umail.ucsb.edu> References: <45C12963.6050902@umail.ucsb.edu> Message-ID: <20070131224117.25c8bx2uv1w8occk@webaccess.umail.ucsb.edu> Rama Hoetzlein wrote: > On another note, personally I think we should steer clear of the > AlloBrain as a scientific example because, 1) its not science, and 2) > its too centered around the allosphere. Perhaps we can come up with > another example that is both novel visual + aural research. Yes, it's not a traditional scientific anything. Do you want to specifically focus on a scientific application? If so, why? Also, and maybe you just weren't aware of this, the AlloBrain project does not have to be run in the Allosphere. It has no other connection to the Allosphere other than it has been run in there. 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 Wed Jan 31 22:54:13 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Wed Jan 31 22:54:20 2007 Subject: [Tdg] Presentation stuff In-Reply-To: <20070131224117.25c8bx2uv1w8occk@webaccess.umail.ucsb.edu> References: <45C12963.6050902@umail.ucsb.edu> <20070131224117.25c8bx2uv1w8occk@webaccess.umail.ucsb.edu> Message-ID: <45C18E95.6040001@umail.ucsb.edu> > Yes, it's not a traditional scientific anything. Do you want to > specifically focus on a scientific application? If so, why? Also, > and maybe you just weren't aware of this, the AlloBrain project does > not have to be run in the Allosphere. It has no other connection to > the Allosphere other than it has been run in there. > I don't want to focus on scientific research any more than any other kind of research - i think our system is for all kinds. However, if we are claiming that Mint will be a general interdisciplinary research tool, which includes scientific research, i think we should use a real scientific example.. Many who have visited the allosphere associate the AlloBrain with the sphere since that is the only thing shown in there so far (far as i know). Does it have another name besides AlloBrain? rama From ljputnam at umail.ucsb.edu Wed Jan 31 23:06:13 2007 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Wed Jan 31 23:06:26 2007 Subject: [Tdg] Meeting with the Big Men In-Reply-To: <1079b050701311616i36175460ne4b71feb8107971d@mail.gmail.com> References: <1079b050701311616i36175460ne4b71feb8107971d@mail.gmail.com> Message-ID: <20070131230613.2sge2ckvk0ocwcow@webaccess.umail.ucsb.edu> Is the meeting on for tomorrow at 2? I'm sorry I haven't been attending the meetings, I've been writing too many papers... FYI, we did have a discussion last spring with Xavier (Rama and I) about possibly having him and Tobias as PIs, but I don't remember exactly what the reasons were for us not pursuing something together. Besides those two, I think Stephen would be a valuable PI because he has a lot of experience with distributed system and general software design. I also think it would be good at some point for us to sit down with Xavier and JoAnn to learn what research they have been doing on all of the software packages out there for doing distributed rendering, etc. We certainly don't want to "reresearch." Lance Wesley Smith wrote: > Hi everyone, > I just had a meeting with Manjunath, Turk, and Legrady. Some > interesting points came up. Basically, George and Turk expressed > "surprise" at being the PIs on Mint. They suggested that we should > find more appropriate people such as Pope, Tobias, and Xavier (even if > he's only going to be here for a few more months). They said we > should make sure to get such people to our presentation so that they > can see the project and potentially advise us. We need to interact > with the faculty more about the project. We also need to say why it's > research and not just "development" and where we could publish. We > need to say in our presentation what kind of product or demo we could > have by when. I think all of you will have the same kind of meeting > in the near future, so be prepared to discuss this kind of stuff. > Tommorrow we should go through some of this business. > > wes > _______________________________________________ > 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 Wed Jan 31 23:31:50 2007 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Wed Jan 31 23:32:00 2007 Subject: [Tdg] Meeting with the Big Men In-Reply-To: <20070131230613.2sge2ckvk0ocwcow@webaccess.umail.ucsb.edu> References: <1079b050701311616i36175460ne4b71feb8107971d@mail.gmail.com> <20070131230613.2sge2ckvk0ocwcow@webaccess.umail.ucsb.edu> Message-ID: <45C19766.5040608@umail.ucsb.edu> Join us! (yes, meeting is on). I hope to bring in some possible slides to start off.. we can discuss more what we want and make sure our group goals are consistent. One of the things we discussed in meetings so far is that we want to distance our project somewhat from the allosphere as our system will be a generic research tool (ie. we don't want to be brought into things that are clearly allosphere research - at least i'd rather work on Mint). While Xavier and JoAnn have done some research on generic platforms, I think they are also looking at specific tools to enable the allosphere - something we may not want to get to involved with.. Part of the reason we have not had much faculty input so far is because we - as professional students - had enough of a group vision that we wanted to make the project more solid before getting outside input. I think this has helped us as a group. We've all made sacrifices so that the group vision could be stronger. Now that the core design decisions are made I think the timing is good. As this project opens up more, if we want to keep it as a generic research tool