Community Core Vision (Beta)

I agree completely with what you said about notifying openframeworks dev guys about the code fixes and I intend to do so. However, if its true what you said about openframeworks being just a dependency and that it should not be modified, then it would be a good idea to restructure the tbeta/ccv source code in such a way to include openframeworks in a form of binary library and not the source (like all other dependencies).
Having said all that, PS3Eye multicam for tbeta/ccv (Windows) is in its own code branch (http://nuicode.svnrepository.com/svn/tbeta/branches/tbeta/Windows-PS3EyeMuticam/) and these changes are not commited to the main code trunk.

Seth Sandler wrote:

No openframeworks code should be changed unless the openframeworks dev team is notified. This will create problems as the goal is to NOT host openframeworks code and use it as a dependency instead. Modifying their code (whether to correct bugs or other) without notifying them is not appropriate and will cause significant issues down the road.

Alexander Popovich wrote:

I agree completely with what you said about notifying openframeworks dev guys about the code fixes and I intend to do so. However, if its true what you said about openframeworks being just a dependency and that it should not be modified, then it would be a good idea to restructure the tbeta/ccv source code in such a way to include openframeworks in a form of binary library and not the source (like all other dependencies). Having said all that, PS3Eye multicam for tbeta/ccv (Windows) is in its own code branch (http://nuicode.svnrepository.com/svn/tbeta/branches/tbeta/Windows-PS3EyeMuticam/) and these changes are not commited to the main code trunk.

Yeah, no problem Alex. I just wanted to make sure it's clear (for everyone< - not aimed just at you) that any changes to core openframeworks code should be reported to them so they can make the appropriate changes to their codebase. As for having a binary library, that's not currently how openframeworks chooses to operate and that's a discussion that should probably be taken up with them. With that said, the concept is the same and ideally all openframeworks code should be stripped from the CCV repository so that there aren't mismatches between code or OF updates and there isn't a community expectation of maintaining both openframeworks and CCV code which is a much bigger task. I'm sure the community will appreciate the work you're doing; my goal isn't to downgrade that by any means. :)

Seth Sandler wrote:

Alexander Popovich wrote:

I agree completely with what you said about notifying openframeworks dev guys about the code fixes and I intend to do so. However, if its true what you said about openframeworks being just a dependency and that it should not be modified, then it would be a good idea to restructure the tbeta/ccv source code in such a way to include openframeworks in a form of binary library and not the source (like all other dependencies). Having said all that, PS3Eye multicam for tbeta/ccv (Windows) is in its own code branch (http://nuicode.svnrepository.com/svn/tbeta/branches/tbeta/Windows-PS3EyeMuticam/) and these changes are not commited to the main code trunk.

Yeah, no problem Alex. I just wanted to make sure it's clear (for everyone - not aimed just at you) that any changes to core openframeworks code should be reported to them so they can make the appropriate changes to their codebase. As for having a binary library, that's not currently how openframeworks chooses to operate and that's a discussion that should probably be taken up with them. With that said, the concept is the same and ideally all openframeworks code should be stripped from the CCV repository so that there aren't mismatches between code or OF updates and there isn't a community expectation of maintaining both openframeworks and CCV code which is a much bigger task. I'm sure the community will appreciate the work you're doing; my goal isn't to downgrade that by any means. :)

Lol... I know what I'm doing and this is not my first program...
All I'm saying is that I make broken code work. I'll leave the philosophical questions/discussion whether this is good or bad to others. My changes are open and anybody willing to analyze them is more than welcome to do so. None of these changes affected the openFrameworks runtime behavior and underlying API. So in no way this is intended to be another branch of their code. Btw, it is pretty amusing reading some of the comments openframeworks dev team left in their code...

Lol... I know what I'm doing and this is not my first program... All I'm saying is that I make broken code work. I'll leave the philosophical questions/discussion whether this is good or bad to others. My changes are open and anybody willing to analyze them is more than welcome to do so. None of these changes affected the openFrameworks runtime behavior and underlying API. So in no way this is intended to be another branch of their code. Btw, it is pretty amusing reading some of the comments openframeworks dev team left in their code...

I didn't realize that I said you didn't know what you're doing; it's clear you do. :P If that's the case, then I apologize.

Alexander Popovich wrote:

I agree completely with what you said about notifying openframeworks dev guys about the code fixes and I intend to do so. However, if its true what you said about openframeworks being just a dependency and that it should not be modified, then it would be a good idea to restructure the tbeta/ccv source code in such a way to include openframeworks in a form of binary library and not the source (like all other dependencies). Having said all that, PS3Eye multicam for tbeta/ccv (Windows) is in its own code branch (http://nuicode.svnrepository.com/svn/tbeta/branches/tbeta/Windows-PS3EyeMuticam/) and these changes are not committed to the main code trunk.

They are 2 things that is wrong with the way of theses changes about multicam (which is not multicam, just ps3 dual cam.)

The first is, creating a new branch with all changes in, without committing the first svn cp, is hard. Why all changes about multicam have been developed in a closed environment, and commit the things when all is done ? How about other people who are trying to develop on it too ?
The second is, making changes on Ofx core shouldn't be there. Specially typo one, this make the tracking of changes harder, lot of noise for nothing :/

Yes, the CCV core need to be restructured, and that's what i'm working on. But with new branches like that, and using it to make a release in public, make the other work harder. (Why nobody was asked about the public release ? How about linux or macosx version ?)

I'm feeling very sad about all of this, and the management :/

Mathieu Virbel wrote:

Alexander Popovich wrote:

I agree completely with what you said about notifying openframeworks dev guys about the code fixes and I intend to do so. However, if its true what you said about openframeworks being just a dependency and that it should not be modified, then it would be a good idea to restructure the tbeta/ccv source code in such a way to include openframeworks in a form of binary library and not the source (like all other dependencies). Having said all that, PS3Eye multicam for tbeta/ccv (Windows) is in its own code branch (http://nuicode.svnrepository.com/svn/tbeta/branches/tbeta/Windows-PS3EyeMuticam/) and these changes are not committed to the main code trunk.

They are 2 things that is wrong with the way of theses changes about multicam (which is not multicam, just ps3 dual cam.)

The first is, creating a new branch with all changes in, without committing the first svn cp, is hard. Why all changes about multicam have been developed in a closed environment, and commit the things when all is done ? How about other people who are trying to develop on it too ? The second is, making changes on Ofx core shouldn't be there. Specially typo one, this make the tracking of changes harder, lot of noise for nothing :/

Yes, the CCV core need to be restructured, and that's what i'm working on. But with new branches like that, and using it to make a release in public, make the other work harder. (Why nobody was asked about the public release ? How about linux or macosx version ?)

I'm feeling very sad about all of this, and the management :/

Not sure what are you talking about? The branch was created directly from the latest current trunk copy. The whole development process took several hours, so I'm not sure what you mean by committing it when it was done. This is how the svn development is done. Checkout-change-commit. Closed environment? The code is there so anybody can have a look at it. I don't know what closed environment are you talking about.
The changes made to the OF are due to many people complaining about gigs of log files being generated on their machines after they exit ccv. The exit delay is annoying bug and instead of fixing it, OF dev team and everybody else is blaming it on OpenGL 'bug'. This is bogus. Having a non functional window close button is simply a bad design. Therefore, it was fixed here so that application exits cleanly and there are no threads left running in the background and no log files are being generated without user's knowledge.
The branch was created so that all of this is tested. Once everybody is happy with the changes (which apparently is difficult) it will be merged back to the code trunk.
The release is not a full blown release but a preview. It is also Windows only since the multi-cam drivers are currently written for Windows.

Alexander Popovich wrote:

Mathieu Virbel wrote:

Alexander Popovich wrote:

I agree completely with what you said about notifying openframeworks dev guys about the code fixes and I intend to do so. However, if its true what you said about openframeworks being just a dependency and that it should not be modified, then it would be a good idea to restructure the tbeta/ccv source code in such a way to include openframeworks in a form of binary library and not the source (like all other dependencies). Having said all that, PS3Eye multicam for tbeta/ccv (Windows) is in its own code branch (http://nuicode.svnrepository.com/svn/tbeta/branches/tbeta/Windows-PS3EyeMuticam/) and these changes are not committed to the main code trunk.

They are 2 things that is wrong with the way of theses changes about multicam (which is not multicam, just ps3 dual cam.)

The first is, creating a new branch with all changes in, without committing the first svn cp, is hard. Why all changes about multicam have been developed in a closed environment, and commit the things when all is done ? How about other people who are trying to develop on it too ? The second is, making changes on Ofx core shouldn't be there. Specially typo one, this make the tracking of changes harder, lot of noise for nothing :/

Yes, the CCV core need to be restructured, and that's what i'm working on. But with new branches like that, and using it to make a release in public, make the other work harder. (Why nobody was asked about the public release ? How about linux or macosx version ?)

I'm feeling very sad about all of this, and the management :/

Not sure what are you talking about? The branch was created directly from the latest current trunk copy. The whole development process took several hours, so I'm not sure what you mean by committing it when it was done. This is how the svn development is done. Checkout-change-commit. Closed environment? The code is there so anybody can have a look at it. I don't know what closed environment are you talking about. The changes made to the OF are due to many people complaining about gigs of log files being generated on their machines after they exit ccv. The exit delay is annoying bug and instead of fixing it, OF dev team and everybody else is blaming it on OpenGL 'bug'. This is bogus. Having a non functional window close button is simply a bad design. Therefore, it was fixed here so that application exits cleanly and there are no threads left running in the background and no log files are being generated without user's knowledge. The branch was created so that all of this is tested. Once everybody is happy with the changes (which apparently is difficult) it will be merged back to the code trunk. The release is not a full blown release but a preview. It is also Windows only since the multi-cam drivers are currently written for Windows.

I'm talking about the PS3 specific code not enclosed (ifdef/endif) for anything else than windows (i didn't found PS3 multicam driver source code, just dll & lib), some files go dos-only encoding, tuio 1.1 use localhost hardcoded...
Even that, no communication about this with other members/developpers.
Even for the name multicam which is actually incorrect, since it's only dual PS3 on windows. For a proper implementation of multicam, many others ways exists :/

I'm just against the process and the manner of doing such changes. It doesn't reflect as an "opensource" project.

Mathieu Virbel wrote:

Alexander Popovich wrote:

Mathieu Virbel wrote:

Alexander Popovich wrote:

I agree completely with what you said about notifying openframeworks dev guys about the code fixes and I intend to do so. However, if its true what you said about openframeworks being just a dependency and that it should not be modified, then it would be a good idea to restructure the tbeta/ccv source code in such a way to include openframeworks in a form of binary library and not the source (like all other dependencies). Having said all that, PS3Eye multicam for tbeta/ccv (Windows) is in its own code branch (http://nuicode.svnrepository.com/svn/tbeta/branches/tbeta/Windows-PS3EyeMuticam/) and these changes are not committed to the main code trunk.

They are 2 things that is wrong with the way of theses changes about multicam (which is not multicam, just ps3 dual cam.)

The first is, creating a new branch with all changes in, without committing the first svn cp, is hard. Why all changes about multicam have been developed in a closed environment, and commit the things when all is done ? How about other people who are trying to develop on it too ? The second is, making changes on Ofx core shouldn't be there. Specially typo one, this make the tracking of changes harder, lot of noise for nothing :/

Yes, the CCV core need to be restructured, and that's what i'm working on. But with new branches like that, and using it to make a release in public, make the other work harder. (Why nobody was asked about the public release ? How about linux or macosx version ?)

I'm feeling very sad about all of this, and the management :/

Not sure what are you talking about? The branch was created directly from the latest current trunk copy. The whole development process took several hours, so I'm not sure what you mean by committing it when it was done. This is how the svn development is done. Checkout-change-commit. Closed environment? The code is there so anybody can have a look at it. I don't know what closed environment are you talking about. The changes made to the OF are due to many people complaining about gigs of log files being generated on their machines after they exit ccv. The exit delay is annoying bug and instead of fixing it, OF dev team and everybody else is blaming it on OpenGL 'bug'. This is bogus. Having a non functional window close button is simply a bad design. Therefore, it was fixed here so that application exits cleanly and there are no threads left running in the background and no log files are being generated without user's knowledge. The branch was created so that all of this is tested. Once everybody is happy with the changes (which apparently is difficult) it will be merged back to the code trunk. The release is not a full blown release but a preview. It is also Windows only since the multi-cam drivers are currently written for Windows.

I'm talking about the PS3 specific code not enclosed (ifdef/endif) for anything else than windows (i didn't found PS3 multicam driver source code, just dll & lib), some files go dos-only encoding, tuio 1.1 use localhost hardcoded... Even that, no communication about this with other members/developpers. Even for the name multicam which is actually incorrect, since it's only dual PS3 on windows. For a proper implementation of multicam, many others ways exists :/

I'm just against the process and the manner of doing such changes. It doesn't reflect as an "opensource" project.

No changes are made in linux and mac code directories. I'm not even sure why in the repo multiple copies of code were kept for various os flavours. The PS3Eye multicam driver is closed source project. People asked to be able to use it with tbeta/ccv and here I enabled them to do so by integrating it with tbeta/ccv. I can't speak for TUIO 1.1 since I did not touch that code.
Will you stop about multi-cam/dual-cam issue already? The driver is capable of interfacing with more than two cameras.
And Mathieu, how dare you, I put my time and effort into this to make it better for everybody. Instead of learning from it, you complain about the typo I made in a code comment.

Alexander Popovich wrote:

Mathieu Virbel wrote:

Alexander Popovich wrote:

Mathieu Virbel wrote:

Alexander Popovich wrote:

I agree completely with what you said about notifying openframeworks dev guys about the code fixes and I intend to do so. However, if its true what you said about openframeworks being just a dependency and that it should not be modified, then it would be a good idea to restructure the tbeta/ccv source code in such a way to include openframeworks in a form of binary library and not the source (like all other dependencies). Having said all that, PS3Eye multicam for tbeta/ccv (Windows) is in its own code branch (http://nuicode.svnrepository.com/svn/tbeta/branches/tbeta/Windows-PS3EyeMuticam/) and these changes are not committed to the main code trunk.

They are 2 things that is wrong with the way of theses changes about multicam (which is not multicam, just ps3 dual cam.)

The first is, creating a new branch with all changes in, without committing the first svn cp, is hard. Why all changes about multicam have been developed in a closed environment, and commit the things when all is done ? How about other people who are trying to develop on it too ? The second is, making changes on Ofx core shouldn't be there. Specially typo one, this make the tracking of changes harder, lot of noise for nothing :/

Yes, the CCV core need to be restructured, and that's what i'm working on. But with new branches like that, and using it to make a release in public, make the other work harder. (Why nobody was asked about the public release ? How about linux or macosx version ?)

I'm feeling very sad about all of this, and the management :/

Not sure what are you talking about? The branch was created directly from the latest current trunk copy. The whole development process took several hours, so I'm not sure what you mean by committing it when it was done. This is how the svn development is done. Checkout-change-commit. Closed environment? The code is there so anybody can have a look at it. I don't know what closed environment are you talking about. The changes made to the OF are due to many people complaining about gigs of log files being generated on their machines after they exit ccv. The exit delay is annoying bug and instead of fixing it, OF dev team and everybody else is blaming it on OpenGL 'bug'. This is bogus. Having a non functional window close button is simply a bad design. Therefore, it was fixed here so that application exits cleanly and there are no threads left running in the background and no log files are being generated without user's knowledge. The branch was created so that all of this is tested. Once everybody is happy with the changes (which apparently is difficult) it will be merged back to the code trunk. The release is not a full blown release but a preview. It is also Windows only since the multi-cam drivers are currently written for Windows.

I'm talking about the PS3 specific code not enclosed (ifdef/endif) for anything else than windows (i didn't found PS3 multicam driver source code, just dll & lib), some files go dos-only encoding, tuio 1.1 use localhost hardcoded... Even that, no communication about this with other members/developpers. Even for the name multicam which is actually incorrect, since it's only dual PS3 on windows. For a proper implementation of multicam, many others ways exists :/

I'm just against the process and the manner of doing such changes. It doesn't reflect as an "opensource" project.

No changes are made in linux and mac code directories. I'm not even sure why in the repo multiple copies of code were kept for various os flavours. The PS3Eye multicam driver is closed source project. People asked to be able to use it with tbeta/ccv and here I enabled them to do so by integrating it with tbeta/ccv. I can't speak for TUIO 1.1 since I did not touch that code. Will you stop about multi-cam/dual-cam issue already? The driver is capable of interfacing with more than two cameras. And Mathieu, how dare you, I put my time and effort into this to make it better for everybody. Instead of learning from it, you complain about the typo I made in a code comment.

It's not about "your" work, since i didn't check who committed that and who are involved in the process. At least, not all developers. Again, it's not against YOU, it's against the way to do it. And you known, everybody here put time and effort. And no, i don't complain about a simple code comment. I've explicitly explain why i think the process is wrong. I would be glade to help, but really, just think about the other side. The side of other people who are also trying to make it better.

Maybe the real thing is miscommunication about this.

And for the closed driver, ok, you've included a way to use it in CCV, but it don't care about other platform. And no a talk have been done about "how to integrate multicam in ccv". Maybe i've missed this thread, maybe not.

No changes are made in linux and mac code directories. I'm not even sure why in the repo multiple copies of code were kept for various os flavours. The PS3Eye multicam driver is closed source project. People asked to be able to use it with tbeta/ccv and here I enabled them to do so by integrating it with tbeta/ccv. I can't speak for TUIO 1.1 since I did not touch that code. Will you stop about multi-cam/dual-cam issue already? The driver is capable of interfacing with more than two cameras. And Mathieu, how dare you, I put my time and effort into this to make it better for everybody. Instead of learning from it, you complain about the typo I made in a code comment.

It's not about "your" work, since i didn't check who committed that and who are involved in the process. At least, not all developers. Again, it's not against YOU, it's against the way to do it. And you known, everybody here put time and effort. And no, i don't complain about a simple code comment. I've explicitly explain why i think the process is wrong. I would be glade to help, but really, just think about the other side. The side of other people who are also trying to make it better.

Maybe the real thing is miscommunication about this.

And for the closed driver, ok, you've included a way to use it in CCV, but it don't care about other platform. And no a talk have been done about "how to integrate multicam in ccv". Maybe i've missed this thread, maybe not.

I'm not sure why or how this got out of hand really. This was never about attacking an individual. If that's the aim, we can make it about that, but it's really counter-productive. I'm sensing a bit of elitist talk about "bogus" claims (when there's clear documentation about such bugs - was on the GLUT official FAQ) and the unwillingness to take constructive criticism. If we all have the same goals, I'm not sure what the issue is and why there can't be a healthy discussion about the various ways to complete the same task. No one is picking on anyone else, so if that's the thought process, it needs to change. Anyone and everyone who contributes code is appreciated; I'm not sure why it's so hard to 'play nice' here.