Psyche Project
From Sfvlug
Line 8: | Line 8: | ||
More to follow soon! | More to follow soon! | ||
+ | |||
+ | The following contribution by Steve with comments by Kurt regarding the status of the Psyche project: | ||
+ | == Status == | ||
+ | |||
+ | PSYCHE is unviable in its current state. The only possible way to remedy this solution would be to contact CMU and ask them whats up. | ||
+ | Given the fact that no ones expressed any interest in pursing anything SCALE related whatsoever I doubt this will happen in | ||
+ | the time left before the expo in February. | ||
+ | |||
+ | ===Comment=== | ||
+ | I'll try contacting someone at CMU this next week. Perhaps we should consider backup plans no matter the results of any attempt to get Sphinx2 working better. This has been a continuing problem. --[[User:Miasma|Miasma]] 19:40, 24 November 2006 (EST) | ||
+ | |||
+ | == Possible Alternatives == | ||
+ | |||
+ | Voice Synthesis Possibilities: | ||
+ | |||
+ | log watchers | ||
+ | service checkers | ||
+ | status checkers | ||
+ | state checkers | ||
+ | harverster readers | ||
+ | ebook readers | ||
+ | documentation readers | ||
+ | security monitors | ||
+ | etc... | ||
+ | |||
+ | Voice Recognition Possibilities: | ||
+ | |||
+ | Pursue a different voice recognition engine | ||
+ | Pursue a different voice recognition version | ||
+ | Contact CMU to determine sphinx2 status | ||
+ | Contact CMU to determine possible/best alternative | ||
+ | ===Comment=== | ||
+ | These are good ideas no matter the result of any attempt to improve on Sphinx2. --[[User:Miasma|Miasma]] 19:42, 24 November 2006 (EST) | ||
+ | |||
+ | == Approach == | ||
+ | |||
+ | 1. Come to table with discussed project possibilities and any backround/code thats available. | ||
+ | |||
+ | 2. Set precedent for the meeting stating it won't be a social meeting and socializers will be asked to leave. | ||
+ | |||
+ | 3. Field the groups capabilities | ||
+ | interests | ||
+ | coding level | ||
+ | languages | ||
+ | topic experience level | ||
+ | no of weekly hours they can devote | ||
+ | contact information (preferably telephone numbers in an effort to establish perceived accountability and show we're serious about time based progress) | ||
+ | |||
+ | 4. Discuss potential project viability and fallback given the limited time alloted (perhaps consider working 2 projects at once). | ||
+ | |||
+ | 5. Open floor to alternative projects not discussed in case the group feels theres something with more potential. | ||
+ | |||
+ | 6. Decide which project is most suitable based on the groups skills, desires, and most importantly donated time available. | ||
+ | |||
+ | 7. Possibly have a mini intro to next meeting to try to bring some people up to speed on a given language | ||
+ | |||
+ | 8. Write pseudocode to determine what code is needed. Assign Classes/Methods/Functions to groups members based on | ||
+ | the pseudocode spec (ie we need these classes and these methods/functions which takes this as input and returns | ||
+ | output in this form). | ||
+ | |||
+ | 9. Create meeting outline before meeting stating the amount of time you'd like to spend discussing each item (adhereing to the | ||
+ | alloted time on the more irrelevant issues that might sidetrack discussion). | ||
+ | |||
+ | 10. Setup some mechanism of peer review (easiest method would be to assign any one part of the project to multiple people | ||
+ | hopefully we'll see results from at least one of them). | ||
+ | |||
+ | 11. Have definate plan and timetable for all actions when leaving the meeting, make sure people understand their task, what it entails, | ||
+ | the time it might take, and its due date. Also discuss alternatives to critical action items. | ||
+ | |||
+ | 12. Set precedent for problem solving. If you can't accomplish this task, what alerternatives can YOU as part of the group recommend | ||
+ | or persue to achieve this goal by the deadline. | ||
+ | |||
+ | 13. Communication! Point to sfvlug wiki, request that people spend 2 min daily checking out the SCALE projects state. | ||
+ | |||
+ | 14. Write everything down! | ||
+ | |||
+ | 15. Hand people a physical piece of paper with their task written on it. They won't forget and there won't be question as to what their | ||
+ | task was. Record the task in the project ledger. | ||
+ | |||
+ | 16. Post meeting notes (minus contact information that can't be made public) and whose in charge of which task or tasks to enable perfect | ||
+ | information and dialoging. | ||
+ | |||
+ | 17. Set a precedent to try to accomplish your assigned task as quickly as possible to enable task reassignment in the event they can | ||
+ | no longer accomplish their task (this might give people too much of an out and they may take the task alot less seriously if this is | ||
+ | even discussed, possibly only state to accomplish your task well before the deadline). | ||
+ | |||
+ | 18. Socialization can occur before or after the meeting! | ||
+ | |||
+ | ===Comment=== | ||
+ | My assumption is that all this would be accomplished in a meeting proposed in the following section. We should probably bring this up at the next regular meeting to see how many would be willing and able to spend some time on this project. --[[User:Miasma|Miasma]] 19:47, 24 November 2006 (EST) | ||
+ | |||
+ | == Timetable == | ||
+ | |||
+ | Max 7 weeks losing thansgiving and xmas/newyears weeks to relatives and responsibilities and the fact that the SCALE | ||
+ | meeting hasn't even been announced. | ||
+ | |||
+ | == Action Items == | ||
+ | |||
+ | Have a SCALE related meeting ASAP | ||
+ | Bring project options to the table at the meeting annoucement in hopes to limit the groups discussion in a nonstructured meeting environment. | ||
+ | |||
+ | == About This Document == | ||
+ | |||
+ | This is all off the top of the head atm if its severity or content is wrong tweak it. I'm tired of typing this stuff so hopefully | ||
+ | I'll get back to this later (or someone else will). |
Revision as of 00:36, 27 November 2006
Contents |
Psyche Project Page
Psyche is a project we started for SCALE in 2003. It was designed to demonstrate speech recognition and speech synthesis on the GNU/Linux platform. We had lines of people waiting to talk to Psyche at the show. Since it was such a big hit and we will continue as long as interest holds up.
In the tradition of *nix programming Psyche itself is basically just a glue that cobbles together some existing tools. The main components being Sphinx and Festival along with a few other tools to provide a system of speech recognition and speech synthesis on a Linux based PC. Most of the original code was written in Python by Steve Petrovits & Rick Wang. Since then we have made improvements including a new module that reads IRC chat logs aloud in real time as they arrive.
If you are fluent in Python or would like to become fluent this is a great project to join. You can find some project files here. They may not be completely up to date but this disclaimer will be removed after we insure they are.
More to follow soon!
The following contribution by Steve with comments by Kurt regarding the status of the Psyche project:
Status
PSYCHE is unviable in its current state. The only possible way to remedy this solution would be to contact CMU and ask them whats up. Given the fact that no ones expressed any interest in pursing anything SCALE related whatsoever I doubt this will happen in the time left before the expo in February.
Comment
I'll try contacting someone at CMU this next week. Perhaps we should consider backup plans no matter the results of any attempt to get Sphinx2 working better. This has been a continuing problem. --Miasma 19:40, 24 November 2006 (EST)
Possible Alternatives
Voice Synthesis Possibilities:
log watchers service checkers status checkers state checkers harverster readers ebook readers documentation readers security monitors etc...
Voice Recognition Possibilities:
Pursue a different voice recognition engine Pursue a different voice recognition version Contact CMU to determine sphinx2 status Contact CMU to determine possible/best alternative
Comment
These are good ideas no matter the result of any attempt to improve on Sphinx2. --Miasma 19:42, 24 November 2006 (EST)
Approach
1. Come to table with discussed project possibilities and any backround/code thats available.
2. Set precedent for the meeting stating it won't be a social meeting and socializers will be asked to leave.
3. Field the groups capabilities
interests coding level languages topic experience level no of weekly hours they can devote contact information (preferably telephone numbers in an effort to establish perceived accountability and show we're serious about time based progress)
4. Discuss potential project viability and fallback given the limited time alloted (perhaps consider working 2 projects at once).
5. Open floor to alternative projects not discussed in case the group feels theres something with more potential.
6. Decide which project is most suitable based on the groups skills, desires, and most importantly donated time available.
7. Possibly have a mini intro to next meeting to try to bring some people up to speed on a given language
8. Write pseudocode to determine what code is needed. Assign Classes/Methods/Functions to groups members based on the pseudocode spec (ie we need these classes and these methods/functions which takes this as input and returns output in this form).
9. Create meeting outline before meeting stating the amount of time you'd like to spend discussing each item (adhereing to the alloted time on the more irrelevant issues that might sidetrack discussion).
10. Setup some mechanism of peer review (easiest method would be to assign any one part of the project to multiple people hopefully we'll see results from at least one of them).
11. Have definate plan and timetable for all actions when leaving the meeting, make sure people understand their task, what it entails, the time it might take, and its due date. Also discuss alternatives to critical action items.
12. Set precedent for problem solving. If you can't accomplish this task, what alerternatives can YOU as part of the group recommend or persue to achieve this goal by the deadline.
13. Communication! Point to sfvlug wiki, request that people spend 2 min daily checking out the SCALE projects state.
14. Write everything down!
15. Hand people a physical piece of paper with their task written on it. They won't forget and there won't be question as to what their task was. Record the task in the project ledger.
16. Post meeting notes (minus contact information that can't be made public) and whose in charge of which task or tasks to enable perfect information and dialoging.
17. Set a precedent to try to accomplish your assigned task as quickly as possible to enable task reassignment in the event they can no longer accomplish their task (this might give people too much of an out and they may take the task alot less seriously if this is even discussed, possibly only state to accomplish your task well before the deadline).
18. Socialization can occur before or after the meeting!
Comment
My assumption is that all this would be accomplished in a meeting proposed in the following section. We should probably bring this up at the next regular meeting to see how many would be willing and able to spend some time on this project. --Miasma 19:47, 24 November 2006 (EST)
Timetable
Max 7 weeks losing thansgiving and xmas/newyears weeks to relatives and responsibilities and the fact that the SCALE meeting hasn't even been announced.
Action Items
Have a SCALE related meeting ASAP Bring project options to the table at the meeting annoucement in hopes to limit the groups discussion in a nonstructured meeting environment.
About This Document
This is all off the top of the head atm if its severity or content is wrong tweak it. I'm tired of typing this stuff so hopefully I'll get back to this later (or someone else will).