----- Original Message -----
From: "Lee Goddard" <[EMAIL PROTECTED]>
Sent: Thursday, May 16, 2002 2:23 AM


> >hehehe -- is that to say that you'd like to see a module that allows
> >plug-n-play text->midi conversion? =)
>
> Well.... yes!

Cool, I'll get on it =)

> >TransMid is moving more and more towards a live performance
> >tool, rather than one that deals with MIDI files.  If the module were of
> >that sort, it would be restricted to the Win32 platform.
>
> Bum. We have a *nix MIDI and a WIn MIDI mod -- now to combine
> the two. When I get my bloody MIDI gear here from the UK, I can do
> that sorta thing; now I'm restricted to files, I'm afraid.

Well, it's entirely possible to add two modules to it,
MIDI::Trans::Win32Play and MIDI::Trans::UnixPlay, and make the interfaces
exactly the same...  Then again, I've looked at the MIDI::Music module, it
looks pretty simple...  I just don't have a test platform, currently!

To add playback, that could easily be done by adding another callback, for
when the final note is generated...  Could return the actual note on/off
data, or could just leave that up to the user to handle...

> >- define a delimiter to split input text on
> >- define attributes of the input text (#elements, # words, # lines,
> >#sentances, #punct, etc.)
>
> I thought you'd done those bits?

Well, yes, but not in a reasonably portable manner...  The code is really
ugly in TransMid, considering that so much of it was written in a hurry.
Won't require too much mangling though...

> >Would it need to do much more?
>
> No, but then that could keep many people going for a long time.
> Well, the former bit: this last list looks easy enough doesn't it?
> Run of the mill programming.

Indeed.  The module will be knocked out pretty quickly, just have one script
to write today for work, and then I'll start on it.

> But I'd like to have a look some
> more: I read something of algorithms inserted at my leisure  -
> that sounds cool.

? I'm a bit confused here =)

> Currently, I take a piece of text, and split it into sentances.
> These I split into comma- or (semi-)colon delimited phrases.
> These I split into words. The words I split into syllables.
> That's the easy bit.
>
> What I want to do now two things:
>
> 1. Get a rhythm from a phrase (the title) and use it throughout.
>      Impossible without knowing where in a  word the accent falls,
>      and there is no formula in English. But I have a plan, involving
>      the use of the apostrophes used in (good) dictionaries to mark
>      stress --- if it's not in my rhyming dictionary module then I'll
>      put together a module to read my OED CD-ROM.

Well, there's always the linguistic approach -- we used FSTs implemented in
perl for doing language-oriented text mangling back when I worked at an
online library, there are some good rules for decomposing text, and
transforming it into rules in Speech and Language Processing by Daniel
Jurafsky and James H. Martin.  If you have a good lexicon, i.e.  rhyming
dictionary or OED, that should simplify this task greatly...

Here's a good decompositional database that you can download, and also shows
where the stress is in a word : http://www.speech.cs.cmu.edu/cgi-bin/cmudict

(for example, 'cat' becomes 'K AE1 T' - the 'k' sound, primary stress on the
'ae' sound, 't' sound..)

>      just knock out some Jungle stuff. I don't like Jungle. (I do like
>      Squarepusher, so I'm not far off.)

Jungle?  Why not IDM? hehe.  j/k

> 3.  I do not really want to get into "random" music; I don't
>      wanna use ASCII or UTF values in any way. I don't want to a very
>      rule-based approach: all that is done -- Bach did the latter, and
>      although it was OK, it's not really self-composing.

Well, the output "random" aspect can be fed into a quantization routine of
some sort, to build a more structured output...  That's something I'm
working on (way) down the road...  I'd think that if the rules were
exceptionally dynamic, it'd still be very close to self-composing...  For
example, the 'random output' could be forced first into timing quantization,
and then into scale quantization...  The first step would force a 4/4 (on
the floor!) timing to the events, either dropping or moving those that don't
fall on the grid, and the second step would do some chromatic analysis, and
shuffles octaves / key values about until everything is where it needs to
be.

> 4. I am very interested in using phonemes, though: the pop of  a 'p',
>      the slur of a sibilant ... that would be interesting when combined
>      with word-stress.  Sadly, we might also need word-stress, which
>      requires either a very clever knowledge database (which no-one
>      seems to have yet, STILL), or some human input.  So far, I'm
>      using the latter - taking my text as HTML, and using <I>, <EM>,
>      etc, as word-accent.

I think there are lexicons out there with exactly the data that you're
looking for..  Or rather, algorithms based around some lexicons/corpii which
result in the same data...  One that comes to mind is the Lexical Freenet,
which, although it doesn't give any symbols, it has a 'Rhyme Coercion'
function, at http://www.lexfn.com/  (this function is built from the data
listed above)

Of course, not all words would yet have rhyming data mapped out, OED would
become useful to add to the corpus where CMU left off.

!c (dolljunkie)

Reply via email to