> > > > There's another option that might be worth considering: "plugging" the GMS (or > > Loci) core on top of the Overflow core. I don't think it would be that hard, > > since we already have a node that can exec an executable and return it's stdout. > > That's along the line of what GMS has accomplished and Loci has been trying to > accomplish. This is something we'll need to discuss since we have 3 ideas > about how this can be done. Gms does not 'wrap' external applications, it rather attaches them. Writting a wrapper-plugins is perfectly possible though. > > > But if Overflow were to be a node in GMS, Overflow would have to handle input > from and output to the outside world. I imagine Overflow might need a special > node for doing that. Not needed, an Overflow sub-net can 'accept' any data-description out of the pipeline that it wants. The exsisting & 'to be coded' sensors will take care of the gathering of data and the visual will export the dataflows. In the GMS design dataflows MUST pass a sensor-pipeline-visual path becouse of security\accessability. > An idea that we had for Loci, was that unconnected lines > on a workspace would represent data that would flow to and from the outside. > And since Loci was going to nest workspace in a workspace in a workspace, > etc., and each nested workspace is itself a node, unconnected lines would mean > data flows to a parent. I'd like to see us do that in our collaboration. Unconnected lines? Like 'deadend dataflows'? > > Loci wasn't going to care about the content of the file. We were going to use > XML meta-data to accompany each node, and that could be saved to a file. I'd > like to hear what Jarl has to say about this and how GMS does it. Likewise, gms has data in 5 types availieble to every node\object. (Raw\string\integer\ percentage\boolean). Historic data is cached\stored on disk. > > As for the GUI, I don't think it's a priority for now... we might end up > > rewriting one that best handles the new core (if we merge the 3 projects). Or we > > can always keep 3 different GUIs that use the same core differently... > > Well, I okayed this with our one other dedicated coder (Brad), and we want > Loci to provide a consistent (and very cool, I might add) GUI across the > projects. So, we'll back off of the infrastucture coding and dedicate > ourselves to user interface and general design issues. Maybe the person that coded the core of Loci is interested switching from python to C? > > > Last thing, let's see how much time we have. For the next year, I'm gonna code a > > lot for Overflow, since I use it for my master (in speech processing). What > > about you and the GMS guys? I'm always working on gms.. only recently I started a new project (professional) which will cool down coding in the midweeks :) Weekend are still dedicated to gms..