|
|
Post by hydrophilic on Dec 27, 2015 12:37:14 GMT
SAM 128 Beta (D64) is attached to this post for immediate download: SAM128B.D64 (170.75 KB). Features: - English text-to-speech (Reciter... fixed Western American accent)
- Phonetic text-to-speech (SAM... any accent for many West/European languages)
- Easy (but not automatic) adjustment for NTSC/PAL and 1-or-2 MHz CPU
- Four 'demo' programs in BASIC
- Complete source code (in ASCII, not PETSCII)
Technical: - Reciter (+SAM) uses slightly less than 16K of Bank 1 (47K free for variables)
- SAM uses slightly less than 10K of Bank 1 (53K free for variables)
- Bank 0 is not used at all, except for small stub at $130 (possible cassette problems)
On the D64 file you will find the following files: - DEMO -- BASIC example of Reciter (with pitch/speed changes)
- FAST-SLOW -- BASIC example of settings for 2MHz / 1MHz
- NTSC-PAL -- BASIC example of settings for NTSC / PAL
- KNOBS -- BASIC example of changing various 'voice' settings...
- SAM128.BIN -- phonetic ML program... use alone, or with BASIC
- RECITER128.BIN -- English ML program... use alone, or with BASIC
- SOURCE.ASC -- Complete 6502 source code
This is the "complete" (English) text-to-speech program for the C128. The default settings are for NTSC/1MHz. You can change many settings of SAM/Reciter... in particular, adjust for PAL and/or 2MHz. See the included BASIC programs for real-life examples ("FAST-SLOW" and "NTSC-PAL").
On a real NTSC machine (or VICE @ NTSC speed), it is very hard for me to distinguish between the NTSC and PAL settings. To be specific, I can hear a minor difference, but if you asked me if SAM/Reciter was using PAL or NTSC settings, I could not give a reliable answer!
On VICE @ PAL speed (I do not own PAL C128 for testing), it is very easy to distinguish between the NTSC and PAL settings.
In my opinion, the NTSC/PAL difference is not important. You can adjust SAM/Reciter for NTSC/PAL if you want... but it is not worth the effort (again, my opinion).
More important (hope we all agree), is the difference between SLOW (1MHz) and FAST (2MHz) CPU speed. No matter what options I tried, the C64 (C128 Alpha) version would never sound good at 2MHz (FAST speed). However, I discovered/invented a new variable which I call "Fundamental Wavelength" (FunWL). This new version (C128 Beta) allows you to change this value. Now you can make SAM/Reciter sound "identical" regardless if CPU is running at 1 or 2 MHz.
Note: With the right settings (see example program "FAST-SLOW"), SAM/Reciter sounds about the same to me, regardless of CPU speed. On a technical level, there are minor differences... if you have a good ear, you might actually hear the difference. However, the minor difference(s) makes no impact on sound quality (my opinion... flame away).
This is a Beta release because two important issues remain: - No BASIC wedge (wouldn't it be nice to type SAY"HELLO" in BASIC?)
- No automatic FAST/NTSC/PAL/SLOW correction
In regards to #1, I plan to release a final version with a BASIC wedge... so no worries (just have some patience)!
Issue #2 is the main problem. Right now (Beta version) the user has full control of speech parameters. I could force automatic settings (based on FAST/NTSC/PAL/SLOW), but if I did that, it would destroy any user customization. (One of the cool things about SAM is your ability to customize the speech.) So I really don't know how to proceed... What do you folks think? Should I code automatic adjustments, or should I leave it with default NTSC/1MHz and let the user do the work?
Oh yeah, source code is included on the D64... and I am working on a more human-readable documentation on my website.
Thanks for feedback from forum members on my old/Alpha version. And if you have any questions/comments, post it/them here and now!  [edit]
The documentation on my website is now mostly complete... I hope you find it informative, and if you have some time, please discuss any/all flaws you see... thanks! Oh yeah, flame away about issues with the actual software too [/edit] |
|
|
|
Post by robertb on Jan 2, 2016 6:35:23 GMT
Should I code automatic adjustments, or should I leave it with default NTSC/1MHz and let the user do the work? Hmm, why don't you have one version with the automatic adjustments and one version with the default/manual adjustments? Thanks for all your hard work on this! Happy New Year, Robert Bernardo Fresno Commodore User Group www.dickestel.com/fcug.htm |
|
|
|
Post by hydrophilic on Jan 2, 2016 22:11:05 GMT
Thanks for the idea RobertB. I would hate to maintain two separate versions for such a minor change.
But that got me thinking... what if I leave it with the original C64 settings (NTSC 1MHz), and add a new routine the use can call, like CPUFIX or something. When the user calls that, it would automatically adjust settings? That way, user can have (semi) automatic adjustment if they like, or they can have full manual control if they like. What do you folks think?
Or even better, have it automatically call CPUFIX just once, during Install. If the user wants to switch FAST/SLOW speeds while the program is running (hopefully they won't swap NTSC/PAL chips while running!) they just need to call CPUFIX. Only problem (that I see) with this automatic method is that PAL users would get the PAL-corrected speed, which sounds a bit different than the original (because the C64 version had no PAL correction). Opinions?
Any other suggestions?
P.S., The documentation on my website now refers to the 1MHz/2MHz speed setting as TIMEBASE, instead of FunWL like I posted above. I've also updated the source code but haven't released the update yet... in other words, the source code that is published still calls it FunWL. While writing my web documents, I realized that 'FunWL' variable controls both "PITCH" (as SAM 64 wedge and documentation erroneously refer to wavelength) and SPEED... and I was already referring to (part of) the final "Formant/Fourier" samples as wavelength... so I thought another name (like TIMEBASE) would be more appropriate. This doesn't affect the BASIC programmer at all (because you can't refer to internal variables by name).
Several sections of the documentation were very difficult to write because the original version butchered the English language (referring to wavelength as PITCH and duration as SPEED for example). The concepts can be a challenge to describe with correct English... trying to describe it will explaining and avoiding the mistakes of the original is nearly impossible. Well I tried, but often I sound like an idiot who doesn't know how to write or can't make up his mind... very frustrating.
I'm thinking now I should try again (major re-write) to describe it completely fresh (correct English/technical terms) and then add a footnote that the original documentation and BASIC wedge are retarded? (That still wouldn't solve this issue with the way stress is handled: lower digits = more stress!) *sigh*
|
|
|
|
Post by robertb on Jan 5, 2016 7:02:58 GMT
... what if I leave it with the original C64 settings (NTSC 1MHz), and add a new routine the use can call, like CPUFIX or something. When the user calls that, it would automatically adjust settings? That way, user can have (semi) automatic adjustment if they like, or they can have full manual control if they like. What do you folks think? O.K., after some thought, I vote for this one. Happy New Year, Robert Bernardo Fresno Commodore User Group www.dickestel.com/fcug.htm |
|
|
|
Post by hydrophilic on Jan 7, 2016 3:57:46 GMT
Thanks for the feedback, RobertB! ... Just so we are clear, user would call Install and get original NTSC/1MHz settings... but then the user may call CPUFIX (or whatever) to adjust SAM for NTSC/PAL and 1MHz/2MHz. That does sound like a minor pain for the user, but after thinking (thanks for making me think!) it does seem like the only way to provide "true" compatibility with the original C64 version (i.e., "wrong" settings on a PAL machine, and total disregard for FAST/2Mhz on any machine). Slightly off-topic (tangent?), I've continued to update the documentation on my website... I decided to split it into multiple web pages... hopefully this will make the new user feel safe and comfortable, and yet provide a lot of gritty details missing from the original documentation (and needed for hackers) ... One of my web pages about SAM 128 goes into the technical details of rendering audio. I started with 40-column images, but then I discovered things got too complex to view on a 40-column screen! So what to do? Well, duh... try 80 columns! So then I tried using my BASIC 7.80... I am happy to report SAM/Reciter 128 works just fine with BASIC 7.80 (I haven't tested it with BASIC 8). I submit the following images as "proof" Image of "R" phone (40-column)  Image of "R" phone (80-column)  [Edit]
Oh my God... the VICE emulator failed to capture a screen shot of itself! (The 80-column image, above) So I manually made a screen shot for you... (nothing cheaper than something free!)  [/Edit] |
|
|
|
Post by robertb on Jan 7, 2016 5:10:55 GMT
I am happy to report SAM/Reciter 128 works just fine with BASIC 7.80 (I haven't tested it with BASIC 8). Sweet! You haven't tested it with BASIC 8 (yet), but that reminds me to test SAM 128 with the SuperCPU 128. Happy New Year, Robert Bernardo Fresno Commodore User Group www.dickestel.com/fcug.htm |
|
|
|
Post by hydrophilic on Jan 9, 2016 4:34:47 GMT
SAM 128 (Beta) has no concept of the SuperSCPU. So if you are running at full speed (16MHz? I guess... don't own an S-CPU myself) then it will sound terrible.
I have some code provided by Mirkosoft (another project) which I could adapt to SAM 128... this adaptation would slow down the CPU to 1 (or 2?) MHz speed during speech, but otherwise leave the S-CPU running at original (presumably 16MHz) speed. This is just an idea!! I haven't coded it, and have no way to test it! If anybody wants to volunteer for S-CPU testing, then let me know... I'll write a new version, but you (the volunteer) must test it (I can't).
|
|
|
|
Post by robertb on Jan 10, 2016 6:13:03 GMT
hydrophilic wrote: > SAM 128 (Beta) has no concept of the SuperSCPU. So if you are running at full speed (16MHz? I guess... don't own an S-CPU myself) then it will sound terrible. Ah, I'm traveling in the Los Angeles area right now, so I haven't had time to try out the SuperCPU and SAM 128 (Beta). The SCPU will drive the program at 20 MHz. > I have some code provided by Mirkosoft (another project) which I could adapt to SAM 128... this adaptation would slow down the CPU to 1 (or 2?) MHz speed during speech, but otherwise leave the S-CPU running at original... That sounds good. > I haven't coded it, and have no way to test it! If anybody wants to volunteer for S-CPU testing, then let me know... I'll write a new version, but you (the volunteer) must test it (I can't). I can test the new version on my SCPU 128, as can Al Jackson of the Clark County Commodore Computer Club (of Las Vegas). There you go... two SCPU's, Robert Bernardo Fresno Commodore User Group www.dickestel.com/fcug.htm |
|
|
|
Post by hydrophilic on Jan 12, 2016 23:48:23 GMT
Ah, 20MHz... thanks for the info! Now I'm thinking I can adjust internal settings (TIMEBASE and NOISES) for 20MHz, just like I did for 2MHz. This means (if it works) no SCPU slow down, and also a SCPU user would have more options for adjusting TIMEBASE and NOISES. (At 1MHz, no variation is possible for "classic-SAM" speech... at 2MHz you can play around a little... at 20MHz you would have a wide variety of options.)
|
|
