Conference hydra::amiga_v1

    
    Why not just connect the amiga sound o/p to your sound sampler i/p.
    
    If you're thinking of using pipes or command redirection I don't think it
    would work .
    
    Steve.

    
    >>    Why not just connect the amiga sound o/p to your sound sampler i/p.
    
    Well, because at the moment I don't have a sound sampler. This had of 
    course, occured to me. 

    I do however have some sample 'editing' software, which can read
    .IFF files and allow you to play with the waveforms. What it can also
    do is search memory to see if it can find any sounds in other applications
    that you might be running at the same time, then it allows you to 'steal'
    them, edit and save them as .IFF files

    I use the .IFF files as 'instruments' for Dr.T's MRS.

    I wondered if there was any way of getting at the waveforms for the 
    "ph�nyms" that "Say" uses. It ought to be possible.. 

    D���

    
    If you need some words in particular sampled I can do it for you and
    upload them .
    
    However if you specifically need to get access to the raw phonemes I
    can't help as I'm not sure where they are stored.
    
    Steve..

I've thought of the same thing; the application I had in mind at the time was
creation of a "pre-interpreted" series of spoken phrases, using natural
inflection by the appropriate parameter changes, but without the *very*
perceptible pauses which result from separate invocations of the "say"
system call. I've seen nothing in the RKM *or* any other documentation which
indicates that the architecture allows for this; I think the suggestion of
connecting the output to a digitizer is the best workaround. I thought of it at
the time, but I don't have one either!

It might be possible to hack the "say" code to redirect the output, but it
hasn't been worth *my* time, anyway.

Good luck.

Cheers,
	Bob

Re: .4

>but without the *very* perceptible pauses which result from separate
>invocations of the "say" system call.

Have you tried experimenting with the narrator.device to see if you
could eliminate the "delays"?

I suspect that the delays are a feature, not a bug.  The narrator.device
treats each buffer as a sentence and follows the normal stress rules
for accenting the last syllable of a sentence (read the narrator
documentation on the differences between how the narrator speaks a buffer
that ends in a period versus one that ends in a question mark).

The biggest bug in most Amiga programs that feed the narrator.device is
that they send the narrator a line at a time rather than a sentence
at a time.  For example, feed the SAY CLI command a text file.
Edit the file so that each line contains exactly on sentence and no
sentence is continued on the next line.  The speech is much better.

Re .5:

Sorry, bo, you missed it- the narrator does not accept changes in parameters
such as pitch, speed, etcetera, and so cannot do as good a job as manual
manipulations would allow. The project I was on at the time I wanted to do this
was actually a library of relatively easy-to-use utilities for programmers who
didn't want to get into the down-and-dirty of Amiga speech synthesis routines.
Kind of like Rob Peck's audio tools for sound generation. You'll find the
result, "SpeakEasy," on one of the first AmigaWorld ToolChest disks.

Separate calls to the narrator with altered parameters do cause delays, but not
"intentional" ones- they are simply the result of calculating the required
output "signal" based on the input phoneme string. The pauses, inflection
changes, and such generated by both the translator and the narrator do, as you
say, depend on the input strings of words and phonemes, respectively- the fact
that each of these strings is generated with fixed parameters can create a
requirement to break down what would otherwise be a *single* string into many.

The speech routines are supposedly upgraded in 2.0, though I didn't pay much
attention to the little detail I saw. Kind of lost interest, I guess. Anyway,
the original note on this topic seemed similar in intent: it would just be nice
to be able to "precompile" the calculations used to generate the signals sent to
the audio device, avoiding the hit at runtime. This would allow, for instance,
the "singing Amiga," which is what I was after. Who knows, maybe it's worth the
time to try hacking the code to "redirect" the output or "trap" it when it's
sent to the audio device. Then again, maybe not...

Cheers,
	Bob