Comment 1 by aleksey_s on 2008-10-26 20:44
there is some issues when using stress dictionary (it is used only when dict.dll file can be located):
another dll is staticaly linked with dict.dll and somewhat system can not found it (it is located in synthDrivers folder as dict.dll) so i need copy it to system32 folder. i do not know why its happens, staticaly linked dll is in same folder (synthDrivers) with dll it using.
Changes:
Changed title from "newton synthesizer for NVDA" to "newfon synthesizer for NVDA"

Comment 2 by jteh on 2008-10-26 23:25
I'm not entirely sure what you are requesting here.

• We could add the NVDA (Python) driver to the main NVDA distribution. However, I'm not sure if there is much point if a customised version of the synth needs to be used anyway. Because the user has to download a version of the synth specific to NVDA, the NVDA driver could be distributed with that version. On the other hand, if the same synth dll is used by other packages, then it makes sense to add the NVDA driver to the main NVDA distribution.
• We cannot distribute the synth itself with NVDA.
  • The biggest reason is that it is seriously incompatible with the NVDA license:
  • It is not open source.
  • Perhaps more problematic is the fact that it has restrictions on commercial usage. This is not acceptable for the NVDA project.
  • Also, having different built-in synths for different languages is problematic.
  • It consumes additional space in the distribution. This is a minor issue in this case given its small size.
  • It becomes difficult to manage. Among other things, we would need to implement code to choose a default synthesiser based on the user's language.
    I'm certainly open to suggestions as to how we can make this easier for users to integrate with NVDA, but I believe that including it is not an option.

As a matter of interest, what are the problems with eSpeak's Russian support? Would it be possible to fix them?

Comment 3 by jteh on 2008-10-26 23:26
Changes:
Milestone changed from 0.6 to None

Comment 4 by aleksey_s (in reply to comment 2) on 2008-10-27 12:32
Replying to jteh:

• We could add the NVDA (Python) driver to the main NVDA distribution. However, I'm not sure if there is much point if a customised version of the synth needs to be used anyway. Because the user has to download a version of the synth specific to NVDA, the NVDA driver could be distributed with that version. On the other hand, if the same synth dll is used by other packages, then it makes sense to add the NVDA driver to the main NVDA distribution.

currently it is used in nvda only (and it is developed especially for it), but i thing putting python module inside nvda repository is quite reasonable becouse it will be easier to track changes: i will add more text preprocessing in it while using this synthesizer, also i planning to add ukrainian support.
i hope you can atleast host it onto nvda site, so russian users can to download it easely. or adding feature to download additional resources into nvda installer will be mutch better solution.

• Also, having different built-in synths for different languages is problematic.

not really problematic i think.

• It becomes difficult to manage. Among other things, we would need to implement code to choose a default synthesiser based on the user's language.

okay, just a few lines of code. dictionary with lang codes and synths. if no key - set espeak. what a problem?

I'm certainly open to suggestions as to how we can make this easier for users to integrate with NVDA, but I believe that including it is not an option.

let's think about nvda resources repository?

As a matter of interest, what are the problems with eSpeak's Russian support? Would it be possible to fix them?

espeak uses english phonems to represent russian ones. so for improving one needs record russian phonems and also make more tweaking which is difficult task.

Comment 5 by jteh (in reply to comment 4) on 2008-11-02 20:22
Replying to aleksey_s:

currently it is used in nvda only (and it is developed especially for it), but i thing putting python module inside nvda repository is quite reasonable becouse it will be easier to track changes

My argument here is that the synth has been customised for NVDA, so no one will use the driver unless they use it with the customised version. Thus, having it in the main NVDA distribution is not useful. See also my similar arguments in #187. Tracking changes is definitely worth considering, but this could be done in another repository.

i hope you can atleast host it onto nvda site, so russian users can to download it easely.

We should be able to organise something for this. I assume the author doesn't have any desire to host the customised version on his/her own site?

• Also, having different built-in synths for different languages is problematic.

not really problematic i think.

It makes sense to use a single synth because it keeps size down and makes for a consistent user experience across languages. However, this argument breaks down given eSpeak's poor support for some languages. :) Ultimately, I'd like to see eSpeak's support for other languages improve, but as you say, this is a very difficult task.

Comment 6 by jteh on 2008-11-13 13:20
Mick and i have decided to include the Python driver into the main NVDA distribution. If you have updated the driver for current trunk, please attach it here and we will commit it. Thanks.

Comment 7 by aleksey_s on 2008-11-13 14:50
bzr merge-directive attached

Comment 8 by jteh on 2008-11-14 22:43
I've only had a chance to take a brief look so far. A few thoughts:

• Was your "main" branch up to date when you generated this merge directive? The preview patch includes a lot of stuff that is already in main. This doesn't matter for the merge itself, but it makes review easier if the patch is clean. You can always generate a merge directive against the real "main" branch.
• nit: check() can just return the result of os.path.isfile(); the if check is redundant.
• Any reason for using global functions and having newfon_lib as a global? It isn't particularly important, though I'm curious, especially as it looks liek they used to be in the class.

Comment 9 by aleksey_s (in reply to comment 8) on 2008-11-15 08:41
Replying to jteh:

• Was your "main" branch up to date when you generated this merge directive?

now i tried to make patch after merging with main - it has 500 kb of size. grr!
so newf one is on old revision.

You can always generate a merge directive against the real "main" branch.

describe, may be i am doing something wrong.

• nit: check() can just return the result of os.path.isfile(); the if check is redundant.

ofcourse. sorry for such a newbie entry :)

• Any reason for using global functions and having newfon_lib as a global? It isn't particularly important, though I'm curious, especially as it looks liek they used to be in the class.

i guess calling global functions is faster than class methods? you need'nt to pass self and mutch more.

Comment 10 by jteh (in reply to comment 9) on 2008-11-17 02:51
Replying to aleksey_s:

now i tried to make patch after merging with main - it has 500 kb of size. grr!

When generating a merge directive:

1. Make sure your copy of main is up to date.
2. If the copy of main you just updated is in ../main, do:
   bzr bundle ../main > bundle_file
   I just did this and got a bundle file of about 16 kb.

   You can always generate a merge directive against the real "main" branch.

This is an alternative to merging with a local copy of main. In this case, you do:

bzr bundle http://bzr.nvaccess.org/bzr/nvda/main > bundle-file

• Any reason for using global functions and having newfon_lib as a global? It isn't particularly important, though I'm curious, especially as it looks liek they used to be in the class.

i guess calling global functions is faster than class methods? you need'nt to pass self and mutch more.

Not much more at all. You already have self, so you don't have to do a lookup for that. Looking up an attribute requires a dictionary lookup for both modules and classes, so the performance is the same for that bit. The performance overhead of using object oriented programming is negligible in this case. (This is not always true.) If we were concerned with performance to this degree, we wouldn't be using Python. :)
Having said that, the functions are utility functions which do not require state, so they could either be global functions or class methods (i.e. using the @classmethod decorator).
newfon_lib is essentially a singleton because you can only load one instance of a library into each process, so having it as a global variable or a variable on the class (not the instance) is probably fine.
It's probably ok to leave these alone for this driver. I just wanted to make the point that we generally prefer an object oriented approach where feasible. Some guidelines:

• global variables and functions are good when they are global to the entire module.
• class (not instance) variables and functions are good when they relate to all instances of a given class. You could use a global, but it makes it easier to follow when variables and functions are located within the scope in which they will be used.
• instance variables and functions are best when they relate to (refer to or act upon) individual instances of a given class.
  Of course, there are always cases when these rules should be broken. :)

Comment 11 by aleksey_s on 2008-11-22 21:56
updated merge-directive. besides other, issue with staticaly linked dlls fixed (looks like hack but works).

Comment 12 by jteh on 2008-12-15 06:07
I've removed the merge directives, as there is now a newfon bzr branch.

Unfortunately, this cannot be merged into 0.6p3 because the language freeze for 0.6p3 has begun and the driver includes some strings which need to be translated (such as the description of the synth and the available voice names). It can be merged as soon as 0.6p3 is released.

Comment 13 by zvonimir1 on 2008-12-25 17:20
hmmmm this synth needs to be added to test version
Changes:
Milestone changed from None to 0.6p3

Comment 14 by jteh on 2008-12-25 17:34
Please don't change the ticket information unless you have a particular reason to do so.

The Newfon synth itself will never be added to NVDA because it is not open source and has a restrictive license. See the previous comments for more details.

The NVDA driver for the Newfon synth will be added after 0.6p3. It cannot be added to 0.6p3 due to the language string freeze as noted above.
Changes:
Milestone changed from 0.6p3 to 0.6

Comment 15 by jteh on 2009-02-16 07:41
Merged in r2724. Thanks for your work.
Changes:
State: closed

Comment 16 by Bernd on 2009-08-18 00:03
Hi Alexey, I think you schould link the page where other people can download the special Newphon Synth on the Comunity List.

Comment 17 by aleksey_s (in reply to comment 16) on 2009-08-18 10:38
Replying to Bernd:

Hi Alexey, I think you schould link the page where other people can download the special Newphon Synth on the Comunity List.

Link is already posted on nvda community page. http://ru.nvda-community.org -- NVDA Russian community site.

Attachment app.php added by Slavon on 2014-03-16 19:05
Description:

Attachment func.php added by Slavon on 2014-03-16 19:05
Description:
http://badbeath.tumblr.com/