(01-22-2014, 02:52 AM)braders1986 Wrote: [ -> ]Looks like you care more about claiming this project entirely as your own. No offense, but this is not you're work. Doesn't matter how much you change and contribute to it in the future - unless you start from scratch, this will always be InhexSTER's work. Thanks for working on it for us all, but don't start claiming it like it's you're work when it's not.
Please we don't want to start a rivalry here. Just hope that working together we can keep a tool as bug free as possible, keep good usability and user experience. Also as we have another version that requires custom driver already, I don't want it users becoming divided.
I've been doing the Open Source thing for fifteen years. I'm very familiar with the lifecycle and how things tend to get alternately abandoned then picked up. You all can feel free to think whatever you want, but my aim is to make software that is compelling for me and my friends to use, and whoever else wants to can use it as well. I don't have anything I need to prove.
As you can easily see 100 percent of the changes I've made are still Open Source and updated on Google Code before I even post any binaries. I'm sorry if it somehow offends people to take donations but I've spent several full days on this software already. If you don't think my time has any value, that's not my problem. Yes, I'm pretty offended at some of the poor attitudes here.
(01-22-2014, 03:01 AM)InhexSTER Wrote: [ -> ]Please we don't want to start a rivalry here. Just hope that working together we can keep a tool as bug free as possible, keep good usability and user experience. Also as we have another version that requires custom driver already, I don't want it users becoming divided.
Both developers have been awesome. No one should be getting in the middle of their discussion on how to go about working together.
I for one am thankful that we have at least 2 awesome developers here who are active and attempting to work together. Bugs will happen, but complaining and bitching about who is better will only tend to drive people away from continuing such active public development. I've seen it happen before.
We are all human, trying to do the best we can to support and help each other. Let's all show some respect for the hard work of everyone here, and applaud our ability to do more because we work together. Cooperation is key, and a big part of that is respecting our differences.
I have an idea. Let's hold Google Hangout and whoever is interested, we can all discuss this project. I don't think people quite understand the ramifications of forking a git project; it's not like old version control systems that make that process tedious. Forking and merging back is actually the typical use case put forth by its authors. I don't want to commit anything to anyone's canonical repository until it definitively works, either.
I think a good set of topics for a Hangout would be: Windows version compatibility, Bluetooth adapter compatibility, current bugs which still exist, GUI redesign (who did the branch off of my branch which started implementing a new GUI? it looked good), a framework for haptic feedback (the LED indicator and rumbles alone could communicate so much. Low power warning rumbles would be so nice.), customization features definition (trigger and thumb pad coordinate remapping, various major modes of touchpad use), getting a Windows Installer going, test environment setup, integration of a standard logging framework... What am I missing?
(01-22-2014, 03:21 AM)electrobrains Wrote: [ -> ]I have an idea. Let's hold Google Hangout and whoever is interested, we can all discuss this project. I don't think people quite understand the ramifications of forking a git project; it's not like old version control systems that make that process tedious. Forking and merging back is actually the typical use case put forth by its authors. I don't want to commit anything to anyone's canonical repository until it definitively works, either.
I think a good set of topics for a Hangout would be: Windows version compatibility, Bluetooth adapter compatibility, current bugs which still exist, GUI redesign (who did the branch off of my branch which started implementing a new GUI? it looked good), a framework for haptic feedback (the LED indicator and rumbles alone could communicate so much. Low power warning rumbles would be so nice.), customization features definition (trigger and thumb pad coordinate remapping, various major modes of touchpad use), getting a Windows Installer going, test environment setup, integration of a standard logging framework... What am I missing?
Sounds good enough. The major topic is architecture/API since if it's changed merging becomes harder. my gplus in pm
I think the best thing for us to do is redesign the architecture. There are a lot of subtleties in parallel programming so we ought to carefully get that all right and the program layout will flow from it. At this point I think we are almost ready to move from a prototype stage to a final architecture for the software but the big question in my mind is how do we work the on-board speaker? We absolutely have to start over to get hot-plugging behavior all correct. We should be listening for events indicating new devices appearing and disappearing, rather than polling an enumeration of the devices. We need to track the existing Xinput devices the system has already allocated so we can pick them intelligently and not just steal controller #0. We can get automatic everything working, prevent dual attachment to both the USB and BT interfaces, tie controller preferences to the controller itself not the connection port or order... But we need to start off with a new design if we don't want it to be quite painful.
Here's a thread-level design I envision that should offer pretty optimal petformance: GUI thread does configuration storage synchronously. Plug and Play events when devices show up or disappear may end up in the GUI thread(s). PnP thread spawns individual controller I/O threads which register with a watchdog thread. The watchdog thread handles initiation of shutdowns of I/O threads, and maybe handle temporary disconnection (the serial numbers from the controller sensor readout packets will reset and we have to reintialize it), one thread for input and one for output for each controller, and an I/O thread that communicates between every controller I/O thread and the ScpVbus driver (letting the I/O threads get back to working the native interfaces instead of waiting for the ioctl calls themselves. We'd do a very short queue to keep latency down but minimize packet loss. Actually we can probably gang together multiple sensor readings if necessary [which it will be for using the touchpad like a mouse, just taking the latest measurement will cause crazy warping upon ScpVbus driver back-up]). I guess I'd also make a battery monitor/mode switch communication thread to handle running the rumble motors and LEDs.
There is a lot to consider. I was so excited to get my hands on your prototype, I know we can make something really spectacular together.
I'll be honest, I miss having the touch pad click act as mouse left click. Using the other buttons messes some stuff up when you've already got them assigned to keyboard keys in something like Xpadder.
Any chance the PS button could be the Windows key and the touch pad could be left click?
(01-22-2014, 03:59 AM)electrobrains Wrote: [ -> ]I think the best thing for us to do is redesign the architecture. There are a lot of subtleties in parallel programming so we ought to carefully get that all right and the program layout will flow from it. At this point I think we are almost ready to move from a prototype stage to a final architecture for the software but the big question in my mind is how do we work the on-board speaker? We absolutely have to start over to get hot-plugging behavior all correct. We should be listening for events indicating new devices appearing and disappearing, rather than polling an enumeration of the devices. We need to track the existing Xinput devices the system has already allocated so we can pick them intelligently and not just steal controller #0. We can get automatic everything working, prevent dual attachment to both the USB and BT interfaces, tie controller preferences to the controller itself not the connection port or order... But we need to start off with a new design if we don't want it to be quite painful.
i agree, the speaker connection might need a custom driver, as i don't think the headsets are HID enabled. Also being able to monitor plug/unplug is done by custom driver in ds3 scp. using default driver posses some limitations, also each windows has its own driver version.
Is the speaker in any way usable as a mic? Cause I think that'd be really neat.
(01-22-2014, 04:39 AM)Mkilbride Wrote: [ -> ]Is the speaker in any way usable as a mic? Cause I think that'd be really neat.
A speaker is technically also a mic, so I don't see why not... though it would of course involve some engineering if it is possible to reverse the signal direction.
But aside from the technical of using the speaker as a mic, it's probably doable.. but not needed because headsets (with mic) are supported using the jack... check out a little video blurb about it here
http://youtu.be/3YJi46Y_R7k?t=3m28s