Menu
▾
▴
simca-developers — developers' discussions
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(29) |
Apr
(9) |
May
(1) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Simon de B. <si...@z2...> - 2003-03-19 14:56:47
|
Another thing to think about is how clients will receive the main name-server IOR. Most simple way is the person setting up the name-server mails it to people that need it. But this makes 'spontanious' jamming very difficult. So a central name-server might be an option. Is not very urgent now but good to keep in mind. Ciao, -- Simon de Bakker \/01|)7 workgroup: http://www.void7.org personal homepage: http://www.josos.org |
|
From: Artyom B. <ar...@z2...> - 2003-03-19 14:48:50
|
On Wed, Mar 19, 2003 at 03:24:43PM +0100, Simon de Bakker wrote: > On Wed, Mar 19, 2003 at 03:03:39PM +0100, Artyom Baguinski wrote: > > you keep on answering outside the list aren't you? > you got me; little mistake, pressed 'y' to fast... solution: add the list to your .muttrc and answer with 'L' instead of 'r' in mutt. i've just done that :) and by the way, do you know how to make mutt: - go to old unread mail when i press space / tab (now it only goes to new mail - open preview of a message while keeping list of messages partially visible. it's so frustrating to man muttrc over dialup line :) > > > > During the pipeline creation simca should find out whether the link is > > > local or remote, maybe even what type of link objects support > > > (udp,tcp,..) and ask for hints. Depending it can decide what way is best for this link. > > > > > > > yes this sounds like interesting strategy. i was thinking to make it > > more automagic - like every server has a number of connectors that would > > listen to incoming data and server decides which connector to use for > > every incoming remote link balancing the load of every connector. > > > > but hinting can help - actually at the connection establishing time > > server knows nothing about the load - that's what one could hint. > > The hinting I introduced because different objects may favor different > types of connections. So does a stream object need a reliable tcp > connection and support for larger packet sizes than does e.g. a > realtime sensor input. For the latter it might not be a problem if it > loses some packages along the way if it is delivered as fast as > possible. This is known by the object and can hint the connection > mechanism. The object itself actually doesn't care how it is done, it > might use tcp because the connection mechanism finds the other end needs it, but if needed it can demand. This means objects demanding different connection types cannot connect (unless used with a converter object ?). > we should have "properties properties" (because it depends on a connected properties what kind of connector to use, not on an object). i was thinking, connectors can be even more complicated when they are across the network: imagine we have ffmpeg streaming server available and find it handier to stream media using it instead of sending via tcp "manually". all the other side has to do is to capture the stream. the same mechanizm will allow feed in external (not simca) media streams, as long as ffmpeg client can deal with them. (you should have guessed already - i've installed ffmpeg :) cheers -- Artem Baguinski: <ar...@v2...> <http://www.artm.org/> V2_lab: <http://lab.v2.nl/> <http://www.v2.nl/> |
|
From: Simon de B. <si...@z2...> - 2003-03-19 14:29:36
|
On Wed, Mar 19, 2003 at 03:03:39PM +0100, Artyom Baguinski wrote: > you keep on answering outside the list aren't you? you got me; little mistake, pressed 'y' to fast... > > During the pipeline creation simca should find out whether the link is > > local or remote, maybe even what type of link objects support > > (udp,tcp,..) and ask for hints. Depending it can decide what way is best for this link. > > > > yes this sounds like interesting strategy. i was thinking to make it > more automagic - like every server has a number of connectors that would > listen to incoming data and server decides which connector to use for > every incoming remote link balancing the load of every connector. > > but hinting can help - actually at the connection establishing time > server knows nothing about the load - that's what one could hint. The hinting I introduced because different objects may favor different types of connections. So does a stream object need a reliable tcp connection and support for larger packet sizes than does e.g. a realtime sensor input. For the latter it might not be a problem if it loses some packages along the way if it is delivered as fast as possible. This is known by the object and can hint the connection mechanism. The object itself actually doesn't care how it is done, it might use tcp because the connection mechanism finds the other end needs it, but if needed it can demand. This means objects demanding different connection types cannot connect (unless used with a converter object ?). > something along these lines > -- Simon de Bakker \/01|)7 workgroup: http://www.void7.org personal homepage: http://www.josos.org |
|
From: Artyom B. <ar...@z2...> - 2003-03-19 14:08:30
|
you keep on answering outside the list aren't you? On Wed, Mar 19, 2003 at 01:28:24PM +0100, Simon de Bakker wrote: > > the simca is a CORBA server that provides interface allowing to > > instantiate objects, connect them destroy them, create containers and > > move object from one container to another (construct pipelines in other > > words). > > aye, that's sort of how I looked at it now :) > goody :) and GUI can reuse this later. > > > > simca_object_t is visible as CORBA server that allows to assign / > > request properties, execute commands etc. > > > > once pipeline is created it functions like it used to (like it does in a > > current version), not touching any CORBA things, unless there's a link > > to an object far away, in which case something should be different. but > > what? > > During the pipeline creation simca should find out whether the link is > local or remote, maybe even what type of link objects support > (udp,tcp,..) and ask for hints. Depending it can decide what way is best for this link. > yes this sounds like interesting strategy. i was thinking to make it more automagic - like every server has a number of connectors that would listen to incoming data and server decides which connector to use for every incoming remote link balancing the load of every connector. but hinting can help - actually at the connection establishing time server knows nothing about the load - that's what one could hint. something along these lines |
|
From: Artyom B. <ar...@z2...> - 2003-03-19 12:14:39
|
On Wed, Mar 19, 2003 at 12:34:47PM +0100, Simon de Bakker wrote: > > but they said in that docs > > (it's in ORBit beginner's docs, section about echo client, find it) that > > fist you have to enable TCP/IP in orbit configuration. could you please > > find that out and test and report sucess? :) > > yup > okdan. the sources i've sent were non-compilable, but i guess you fixed the little bugs :) > > > > i'm not thinking about corba and gui at the moment but about distributed > > simca's and i think we can build that functionality on top of corba and > > we can easily connect corba to existing gsimca stuff. have a look how i > > connected a list to CorbaTest server. > > I only doubt the use of corba for control and media streams, because of > overhead. But I don't know how serious that is. Maybe we should try out. look at it like this: the simca is a CORBA server that provides interface allowing to instantiate objects, connect them destroy them, create containers and move object from one container to another (construct pipelines in other words). simca_object_t is visible as CORBA server that allows to assign / request properties, execute commands etc. once pipeline is created it functions like it used to (like it does in a current version), not touching any CORBA things, unless there's a link to an object far away, in which case something should be different. but what? i guess the event handler that is called once object emits something on a outlet-property should be different. and this handler should be installed during simca_objects_connect call if the receiver object is remote. and again this handler shouldn't use corba mechanisms, but should remain simca-specific. i send this to the list for it is worth archiving :) cheers, artm |
|
From: Madris D. <ma...@v2...> - 2003-03-13 15:46:20
|
I put the most recent changes on the Wiki, so please have a look at it as it is now. Cya > Placed Ann=E9's tekst on the Wiki now. |
|
From: Simon de B. <si...@z2...> - 2003-03-13 15:25:08
|
Placed Ann=E9's tekst on the Wiki now. ciao, On Thu, Mar 13, 2003 at 03:40:23PM +0100, Madris Duric wrote: > Ok, we can do it in the wiki.. It's fine with me. > This is just the way I'm used to 'ping-pong'. > The >> thingies don't bother me. :) >=20 > > you should have done it in the wiki, editing in mailing list isn't go= od > > because of the >> thingies. > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open!=20 > Get cracking and register here for some mind boggling fun and=20 > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Simca-developers mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simca-developers --=20 Simon de Bakker \/01|)7 workgroup: http://www.void7.org personal homepage: http://www.josos.org |
|
From: Anne N. <AN...@v2...> - 2003-03-13 14:49:16
|
V2_Jam is V2_Lab's research in Media Jamming. We are especially interested
in the
possibilities to converge different kinds of media into streams, adding
interaction to these
and controlling the entire system in a natural way through physical and
wearable
interfaces in combination with the conventional on-screen controlling
interfaces and future haptic interfaces.
V2_Jam research and development addresses the following issues:
Crossover media. Media jamming consists in creating an art piece from
several pre-
existed or real time generated media. What techniques can one use to create
a coherent
piece from such various sources as text, sound, image, video? What other
media can
one use as input? What the result will be like? These are the questions on
our mind.
Real-time manipulation. Real time aspect of jamming is of high importance.
Just taking
the sources and processing them sequentially by a number of conventional
tools isn't
jamming yet - it's choosing the way to manipulate sources based on their
content that
we're interested in.
In order to start the jamming process participants should be able to change,
control and
contribute to the jam session simultaneously. This is only possible if data
streams and
control can be manipulated in real-time.
Software jamming. There exist many tools to create / process various media.
In a
crossover media one would still like to use some of them, but together,
simultaneously,
real-time. Two common tasks are to get a media stream generated by some
software
and feed it into the other and to control the processing software that
performs "outside"
of it.
User Interface. Our research concerning the user interfaces is not only
oriented towards
influencing the media processing components with the Graphical User
Interface (with
input/output connectors, manual controls, incoming/outgoing hyperlinks and
drop areas),
but also towards the broader area of physical and wearable interfaces.
(the last point on interfacing is somewhat confussing can you explain
what you mean here??)
apart from this a final grammar check is needed and then : finished
ANne
----------------------------------------------------------------------------
--------------
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Simca-developers mailing list
Sim...@li...
https://lists.sourceforge.net/lists/listinfo/simca-developers
|
|
From: Madris D. <ma...@v2...> - 2003-03-13 14:41:02
|
Ok, we can do it in the wiki.. It's fine with me. This is just the way I'm used to 'ping-pong'. The >> thingies don't bother me. :) > you should have done it in the wiki, editing in mailing list isn't good > because of the >> thingies. > |
|
From: Artyom B. <ar...@z2...> - 2003-03-13 14:35:55
|
you should have done it in the wiki, editing in mailing list isn't good because of the >> thingies. On Thu, Mar 13, 2003 at 12:52:27PM +0100, Simon de Bakker wrote: > Hi, > > Ping... > > > V2_Jam is V2_Lab's research in Media Jamming. We are especially interested in the > > possibilities to converge different kinds of media into streams, adding interaction to these > > and controlling the entire system in a natural way through physical and wearable > > interfaces. > > I don't think physical and wearables are the only way of controlling. If > saying it in this explicit context I think you should also mention the > conventional on-screen controlling interfaces and leave an opening for > even other (to be invented?) ways. > > > > > The following are the issues we address in our research. > > > > Crossover media. Media jamming consists in creating an art piece from several pre- > > existed or real time generated media. What techniques can one use to create a coherent > > piece from such various sources as text, sound, image, video? What other media can > > one use as input? What the result will be like? These are the questions on our mind. > > > > Real time manipulation. Real time aspect of jamming is of high importance. Just taking > > the sources and processing them sequentially by a number of conventional tools isn't > > jamming yet - it's choosing the way to manipulate sources based on their content that > > we're interested in. > > In order to start the jamming process participants should be > able to change, control and contribute to the jam session > simultaneously. This is only possible if datastreams and control can be manipulated in real-time. > > (just a little addition to show why real-time manipulation is important > to jamming) > > > > > Software jamming. There exist many tools to create / process various media. In a > > crossover media one would still like to use some of them, but together, simultaneously, > > real time. Two common tasks are to get a media stream generated by some software > > and feed it into the other and to control the processing software that performs "outside" > > of it. > > > > Graphical User Interface. Our research concerning the user interface is based on > > influencing the media processing components in a conventional way, with input/output > > connectors, manual controls, incoming/outgoing hyperlinks and drop areas. > > Should this cover only graphical user interface or the more broad user > interface (including physicals) area, as the latter is also part of the > V2_Jam research area, right? > > > Ciao, > > -- > Simon de Bakker > > \/01|)7 workgroup: http://www.void7.org > personal homepage: http://www.josos.org > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Simca-developers mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simca-developers |
|
From: Madris D. <ma...@v2...> - 2003-03-13 14:35:05
|
Pong... Something like this? Someone, please correct my 'steenkolen' English.. ---------------------------------------------------------------------------- ----------- V2_Jam is V2_Lab's research in Media Jamming. We are especially interested in the possibilities to converge different kinds of media into streams, adding interaction to these and controlling the entire system in a natural way through physical and wearable interfaces in combination with the conventional on-screen controlling interfaces (or any other, still to be invented way.. how do you put that in words??) The following are the issues we address in our research. Crossover media. Media jamming consists in creating an art piece from several pre- existed or real time generated media. What techniques can one use to create a coherent piece from such various sources as text, sound, image, video? What other media can one use as input? What the result will be like? These are the questions on our mind. Real-time manipulation. Real time aspect of jamming is of high importance. Just taking the sources and processing them sequentially by a number of conventional tools isn't jamming yet - it's choosing the way to manipulate sources based on their content that we're interested in. In order to start the jamming process participants should be able to change, control and contribute to the jam session simultaneously. This is only possible if data streams and control can be manipulated in real-time. Software jamming. There exist many tools to create / process various media. In a crossover media one would still like to use some of them, but together, simultaneously, real-time. Two common tasks are to get a media stream generated by some software and feed it into the other and to control the processing software that performs "outside" of it. User Interface. Our research concerning the user interfaces is not only oriented towards influencing the media processing components with the Graphical User Interface (with input/output connectors, manual controls, incoming/outgoing hyperlinks and drop areas), but also towards the broader area of physical and wearable interfaces. ---------------------------------------------------------------------------- -------------- |
|
From: Simon de B. <si...@z2...> - 2003-03-13 11:57:08
|
Hi, Ping... > V2_Jam is V2_Lab's research in Media Jamming. We are especially interested in the > possibilities to converge different kinds of media into streams, adding interaction to these > and controlling the entire system in a natural way through physical and wearable > interfaces. I don't think physical and wearables are the only way of controlling. If saying it in this explicit context I think you should also mention the conventional on-screen controlling interfaces and leave an opening for even other (to be invented?) ways. > > The following are the issues we address in our research. > > Crossover media. Media jamming consists in creating an art piece from several pre- > existed or real time generated media. What techniques can one use to create a coherent > piece from such various sources as text, sound, image, video? What other media can > one use as input? What the result will be like? These are the questions on our mind. > > Real time manipulation. Real time aspect of jamming is of high importance. Just taking > the sources and processing them sequentially by a number of conventional tools isn't > jamming yet - it's choosing the way to manipulate sources based on their content that > we're interested in. In order to start the jamming process participants should be able to change, control and contribute to the jam session simultaneously. This is only possible if datastreams and control can be manipulated in real-time. (just a little addition to show why real-time manipulation is important to jamming) > > Software jamming. There exist many tools to create / process various media. In a > crossover media one would still like to use some of them, but together, simultaneously, > real time. Two common tasks are to get a media stream generated by some software > and feed it into the other and to control the processing software that performs "outside" > of it. > > Graphical User Interface. Our research concerning the user interface is based on > influencing the media processing components in a conventional way, with input/output > connectors, manual controls, incoming/outgoing hyperlinks and drop areas. Should this cover only graphical user interface or the more broad user interface (including physicals) area, as the latter is also part of the V2_Jam research area, right? Ciao, -- Simon de Bakker \/01|)7 workgroup: http://www.void7.org personal homepage: http://www.josos.org |
|
From: Madris D. <ma...@v2...> - 2003-03-13 11:19:35
|
Hi, I just added some pieces to Artem's text that he put online the other day. This is also supposed to be the updated text for the lab's web site.. Please have a look at it and after some ping-ponging we can finally put it online. Madris |
|
From: Artyom B. <ar...@z2...> - 2003-03-12 14:40:00
|
oh my god, never expected that much text from me talking :) On Wed, Mar 12, 2003 at 02:27:20PM +0100, Madris Duric wrote: > ..just finished the interview transcript. > So, this is for now more than enough input > for the article I am going to start working on. |
|
From: Madris D. <ma...@v2...> - 2003-03-12 13:27:50
|
..just finished the interview transcript. So, this is for now more than enough input for the article I am going to start working on. Madris |
|
From: Anne N. <AN...@v2...> - 2003-03-12 09:08:44
|
Ok, artm and co, clear i understand so let's have a meeting monday at 14:00 on this, and also keep in mind that there is the posssibility to include planned projects integrated in the V2_Jam as test cases etc. (floating scanner, stalker show and later in the year kuurooord) all descriptions of these projects are on pancreas or in case of paper versions in the cupboard in the lab ANne > > (in a mean time i'm spending more time with codezebra this week, then i > expected, so no chanes to the plans till next monday. shall we have two > short talks then - one me, simon and madris and the other - me and > anne?) > > > |
|
From: Artyom B. <ar...@z2...> - 2003-03-12 08:48:41
|
On Tue, Mar 11, 2003 at 03:10:54PM +0100, Anne Nigten wrote: > i didn't mean to have completelly new plan, anyway - we can find out how to remain productive following the plan we created with simon and martin. the point is at that moment i didn't realize we were writing a plan with deadlines, i thought it was rather a description of the research. but ok, it's too late to change it, i accept that. in development area we need more detailed plan anyway and that's the one i've started on wiki page. the purpose of detailed plan is to help us achieve the goals of the plan in funding application. does this sound more clear / acceptable? (in a mean time i'm spending more time with codezebra this week, then i expected, so no chanes to the plans till next monday. shall we have two short talks then - one me, simon and madris and the other - me and anne?) > today i briefly discussed this with madris and simon > and proposed an other method > the 3 of you should go through the tasks listed (madris has the real > numbering and schedule now) and check which tasks are 'research' tasks > and which are development / implementation tasks > research in this context means: options to be investigated, things to be > tested, preparation of future features. development and implementation > tasks are clear i guess all need to be documented / and worked out in > the implementation phase. > for once i will be strict on all of you WE ARE NOT ALLOWED to make an > entire new plan, the text from the document has been composed by you, > simon and maarten so interpretation of tasks and small shifts > (especially in the research area ) are allowed but further more 'no'. > there is enough space to fine tune and include other features as we > agreed when composing the project, since several things have been worked > on already so be creative within the frame work of the application > Madris will inform everyone on the schedule etc. > ANne > |
|
From: Anne N. <AN...@v2...> - 2003-03-11 14:10:09
|
today i briefly discussed this with madris and simon and proposed an other method the 3 of you should go through the tasks listed (madris has the real numbering and schedule now) and check which tasks are 'research' tasks and which are development / implementation tasks research in this context means: options to be investigated, things to be tested, preparation of future features. development and implementation tasks are clear i guess all need to be documented / and worked out in the implementation phase. for once i will be strict on all of you WE ARE NOT ALLOWED to make an entire new plan, the text from the document has been composed by you, simon and maarten so interpretation of tasks and small shifts (especially in the research area ) are allowed but further more 'no'. there is enough space to fine tune and include other features as we agreed when composing the project, since several things have been worked on already so be creative within the frame work of the application Madris will inform everyone on the schedule etc. ANne On Tue, 2003-03-11 at 12:01, Artyom Baguinski wrote: > On Mon, Mar 10, 2003 at 06:24:09PM +0100, Anne Nigten wrote: > > Hi all > > yes put me on the low trafic list > > and maybe we should have a short meeting monday next > > to talk about 'secret' issues > > as far as i'm concerned this is more research / compatibility issues > > which should be solved in the mentioned time frame, and documented to > > show this has been considered. no fake should be needed, and i prefer to > > work as transparant as possbible also to our funders > > so let's cook a plan together > > ANne > > > well, the plan that exists now IS fake, because the time is allocated to > tasks that we aren't going to work on. they aren't tasks at all, but > rather ideas to be thought through. but we can't think about those ideas > as one at a time. that's why i proposed to write new better plan. > > what do you mean by "compatibility issues"? > > cheers, > artm > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Simca-developers mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simca-developers > |
|
From: Artyom B. <ar...@z2...> - 2003-03-11 11:05:47
|
On Mon, Mar 10, 2003 at 06:24:09PM +0100, Anne Nigten wrote: > Hi all > yes put me on the low trafic list > and maybe we should have a short meeting monday next > to talk about 'secret' issues > as far as i'm concerned this is more research / compatibility issues > which should be solved in the mentioned time frame, and documented to > show this has been considered. no fake should be needed, and i prefer to > work as transparant as possbible also to our funders > so let's cook a plan together > ANne > well, the plan that exists now IS fake, because the time is allocated to tasks that we aren't going to work on. they aren't tasks at all, but rather ideas to be thought through. but we can't think about those ideas as one at a time. that's why i proposed to write new better plan. what do you mean by "compatibility issues"? cheers, artm |
|
From: Artem B. <ar...@v2...> - 2003-03-11 09:33:53
|
i've started it here: http://www.artm.org/v2_jam/moin/moin.cgi/V2Jam the first part is ready for Madris' editing, use whatever you like from the interview. the second part is just a skeleton. feel free to add new points. artm |
|
From: Anne N. <AN...@v2...> - 2003-03-10 17:23:24
|
Hi all yes put me on the low trafic list and maybe we should have a short meeting monday next to talk about 'secret' issues as far as i'm concerned this is more research / compatibility issues which should be solved in the mentioned time frame, and documented to show this has been considered. no fake should be needed, and i prefer to work as transparant as possbible also to our funders so let's cook a plan together ANne On Mon, 2003-03-10 at 17:16, Artem Baguinski wrote: > hi all > > as we've decided i've created another mailing list for v2jam - > simca-developers. > > anne/lenno: do you wanna be on this (low trafic) list? > we gonna discuss here what are we gonna do about v2jam, wether or not > we're on schedule etc. > > post-interview notes. > > 1. we need another (secret) plan to backup the fake one we have got for > obtaining money. the secret plan should be more clear from our - > developers - point of view, but should at the same time remain > non-public. phases and steps on this internal plan should correspond in > to the vague points we've got on the funding application plan, so we > can report about success in the end. > > roughly the plan is: > - make better plan (this week, artm -> madris, simon, via this list) > - finish the todo list of gsimca v.0.6. - "the puritan release" (till > the end of march, artm/simon) > - come up with texts for UNESCO, lab's website, wondering people who > don't understand what i'm talking about when i say "incapsulation" > (artm -> madris, based on interview and discussions in this list. > this/next week) > - generate ideas / plan for the first GUI (part of gsimca v.0.8, "GUI > release"). (till the end of march, madris with the help of artm) > - split the development: simon starts to work on the first media > objects (gsimca v.0.7), artm - on components/pages/clients framework > (gsimca v.0.8) > > 2. about them names, let's be clear: > > - v2_jam is the v2_lab's research in media jamming. > - simca is a software being developed as part of v2_jam. simca is a > media-processing server. > - i think it'll be fun to come up with some matching name for the > client software. i have no ideas, only that it shouldn't sound at all > like either "v2_jam" or "simca". > - the phrase "the web of media processors" refers to the network of > simca and client instances forming large distributed media processing > pipeline. i find it fine sounding punch phrase :) > > 3. this "look into the flower" compilation of 60s-70s rare numbers from > Blue Note is totally nuts :) i feel like i'm in a James Bond movie or > something. > > cheers, > artm > |
|
From: Artem B. <ar...@v2...> - 2003-03-10 16:28:09
|
hi all as we've decided i've created another mailing list for v2jam - simca-developers. anne/lenno: do you wanna be on this (low trafic) list? we gonna discuss here what are we gonna do about v2jam, wether or not we're on schedule etc. post-interview notes. 1. we need another (secret) plan to backup the fake one we have got for obtaining money. the secret plan should be more clear from our - developers - point of view, but should at the same time remain non-public. phases and steps on this internal plan should correspond in to the vague points we've got on the funding application plan, so we can report about success in the end. roughly the plan is: - make better plan (this week, artm -> madris, simon, via this list) - finish the todo list of gsimca v.0.6. - "the puritan release" (till the end of march, artm/simon) - come up with texts for UNESCO, lab's website, wondering people who don't understand what i'm talking about when i say "incapsulation" (artm -> madris, based on interview and discussions in this list. this/next week) - generate ideas / plan for the first GUI (part of gsimca v.0.8, "GUI release"). (till the end of march, madris with the help of artm) - split the development: simon starts to work on the first media objects (gsimca v.0.7), artm - on components/pages/clients framework (gsimca v.0.8) 2. about them names, let's be clear: - v2_jam is the v2_lab's research in media jamming. - simca is a software being developed as part of v2_jam. simca is a media-processing server. - i think it'll be fun to come up with some matching name for the client software. i have no ideas, only that it shouldn't sound at all like either "v2_jam" or "simca". - the phrase "the web of media processors" refers to the network of simca and client instances forming large distributed media processing pipeline. i find it fine sounding punch phrase :) 3. this "look into the flower" compilation of 60s-70s rare numbers from Blue Note is totally nuts :) i feel like i'm in a James Bond movie or something. cheers, artm |
