Free transcription machines software for linux

Virtual Drum Machine is a simple drum machine.
It works for little endian/linux kind of machines. You may let it work on others machines, but you probably will get troubles with it.
You definitely need oss (or maybe alsa) for sound output, and a posix-like operating system. To let it work on a big endian machine should be painful.
You write a rhythm, then you compile it, then you are able to play it to your sound card or save it to a file.
The Virtual Drum Machine is made of
- the Rhythm Compiler,
- the runtime library.
The Virtual Drum Machine is in the public domain. Who needs a license? money makers? Protection against robbery? let me laugh... Read any text of law, you will see where the robbers reside.
A simple file would look like :
void main_rhythm(void)
{
tempo = 120;
- a
. b
. b
.
- a
.b
- a
.
. b
. b
- a c
. b
}
Install:
Do a "./configure" in the drums directory, then "make", then "make install", it should be alright. You can listen to some examples in the examples/ directory.
Who yo use it?
Write a rhythm. Compile it with "rc". Run the produced program. You are done.
See the examples/ directory to get the point.
When you run an example, try "-h" to get the available options.
It should be self-explanatory.
The rhythm compiler has several options. By running "rc --help", all should be clear.
Technical Details:
The compiler will parse the input file line by line.
If a line starts with "*" or "." (not counting leading white spaces), the whole line is seen as a rhythm line, and is transformed into C code. If not, it is passed as is to the C file.
Beware! You MUST NOT start any C code line by "*" or "."!
You can create as much functions as you want, write any C code you want. But remember that a line starting by "*" or "." is seen as a rhythm line and is translated by "rc" into C code.
You must provide a "void main_rhythm(void)" function, that will be called by the library. It is the starting point of your rhythm. It can be "void main_rhythm(int argc, char *argv[])" too, with common meaning for those parameters (non-C coders will have trouble with the Virtual Drum Machine).
You can change the tempo (ex. "tempo=100;") or the volume (ex "vol=0.4;") at any time. Each sample comes with its own volume and panning (ex. "a.vol = 0.1;" "a.pan=-0.8;"). Volumes range from 0 to what you want. 1 is for the normal volume. Panning ranges from -1 (left) to 1 (right). 0 is center. All values are double. You can use "volume" instead of "vol", and "panning" instead of "pan". There is no global panning, if you want all left, set all samples to left.
To run in stereo mode, dont forget "-s" when running the generated program. It is mono by default.
You absolutely need to compile and run the examples, and read them to get the point out of it!
The "rc.conf" file contains configuration informations. You specify the sample by "sample" followed by its name (the one you will use in your rhythm files), then the file that will be played. The name of the sample must start by a letter, followed by letters and/or numbers (it must be a valid C identifier, without "_" though). The configuration file contains the install directory, used by "rc" to compile your rhythms. Take a look at the one that is provided to see how to use it.
The sound files are simple wav files. They all should be of the same rate, which can be specified to the generated program, using the "-f" option (44100 is the default). (The library only handles very basic wav files, if yours dont work, you probably will have to modify the library for the program to handle it.)
When you add a sample, you must modify "rc.conf" for the changes to appear. The samples are hard-linked to the produced program, so if you change "sample a /some/dir/file1.wav" by "sample a /one/other/dir/file2.wav" in the configuration file, the previously generated programs will still use "/some/dir/file1.wav". You will have to compile them again to take the changes into account.
Enhancements:
- The code has been modified to let gcc 4 compile it.

C++ Machine Objects class library supports a subset of the UML statechart notation for implementing hierarchical state machines in straight C++, similar in spirit to the GoF "State" design pattern.
The currently supported features are hierarchical states, entry and exit actions, state histories, and state variables.
Installation:
The class library as such does not need to be installed. Just include the header file Macho.hpp to make use of it. Prerequisite however is a C++ compiler with sane support for templates.
Included are the example state machines HelloWorld, Example, Microwave and Test. To make the examples run just compile them in the directory they are in, for example:
# GCC
g++ -o microwave Microwave.cpp
# MSVC7
cl /EHsc Microwave.cpp
I like the GoF "State" design pattern. It enables implementing the important concept of state machines with common programming language features. By utilising only basic language mechanisms it is easy to apply in real-life software development.
Another important property that stems from this simplicity is orthogonality, meaning that the pattern can be combined with other design elements, patterns and idioms in arbitrary ways.
In contrast stand the tool supported approaches to state machine creation (of which there is no shortage). Based on code generators and graphical editors, they tend to generate incomprehensible code and forfeit orthogonality by necessarily being outside the domain of the programming language.
Unfortunately the "State" pattern is limited in scope because it does not allow for hierarchical state machines. This is regrettable because flat state machines tend to become unwieldy when getting bigger, for the sheer number of states they produce.
Hierarchical state machines as defined by the statechart notation alleviate this problem by giving an additional structural element through grouping states into hierarchies.
The "State" pattern in its original form is not capable of modeling state hierarchies. The Macho class library extends the concept with this possibility, while keeping the properties of simplicity (there possible) and tool independence from its inspiration.
Enhancements:
- This release adds the feature of backtracking to previous states by using "Snapshots".

State Machine Compiler takes a state machine stored in an .sm file and generates the state pattern classes in nine programming languages.
Its features include default transitions, transition arguments, transition guards, push/pop transitions, and Entry/Exit actions. State Machine Compiler requires Java SE 1.4.1 or better.
Enhancements:
- This release cleans up C# and VB.net debug output using System.Diagnostics.Trace.
- It fixes a number of minor bugs.

High Level Virtual Machine is a toolkit for developing virtual machines for dynamic languages.
The High Level Virtual Machine is:
- Based on LLVM (Low Level Virtual Machine). LLVM is HLVMs sister project. HLVM gains tremendous capability from LLVM in the areas of code generation, bytecode storage, runtime execution, etc.
- Aimed at supporting dynamic languages such as Ruby, Python, Perl, Jython, Haskell, Prolog, etc.
- A complete compiler developers toolkit for creating new languages easily. To write a new compiler, language designers simply write a plugin that describes the language to HLVM and how to translate the grammar productions into HLVMs comprehensive Abstract Syntax Tree (AST). After that, HLVM handles all aspects of code generation, bytecode storage, XML translation, JIT execution or interpretation, and native compilation.
- A language interoperability framework. Because all front end compilers generate code in the same AST, they can interoperate. Use of the runtime library for common constructs (e.g. "string") allow even complex data types to be shared between languages. Users of HLVM can write complex programs in multiple languages and be assured the result can be executed efficiently.
- A code management system including code revisioning, interface versioning, automated recompilation, separation of workspaces, etc.
- Currently under development. Project started April 20th, 2006. Stay tuned to this web site for future developments.

XML::SAX::Machine is a Perl module that can manage a collection of SAX processors.

SYNOPSIS

## Note: See XML::SAX::Pipeline and XML::SAX::Machines first,
## this is the gory, detailed interface.

use My::SAX::Machines qw( Machine );
use My::SAX::Filter2;
use My::SAX::Filter3;

my $filter3 = My::SAX::Filter3->new;

## A simple pipeline. My::SAX::Filter1 will be autoloaded.
my $m = Machine(
#
# Name => Class/object => handler(s)
#
[ Intake => "My::SAX::Filter1" => "B" ],
[ B => My::SAX::Filter2->new() => "C" ],
[ C => $filter3 => "D" ],
[ D => *STDOUT ],
);

## A parser will be created unless My::SAX::Filter1 can parse_file
$m->parse_file( "foo.revml" );

my $m = Machine(
[ Intake => "My::SAX::Filter1" => qw( Tee ) ],
[ Tee => "XML::Filter::SAXT" => qw( Foo Bar ) ],
[ Foo => "My::SAX::Filter2" => qw( Out1 ) ],
[ Out1 => $log ],
[ Bar => "My::SAX::Filter3" => qw( Exhaust ) ],
);

WARNING: This API is alpha!!! It will be changing.

A generic SAX machine (an instance of XML::SAX::Machine) is a container of SAX processors (referred to as "parts") connected in arbitrary ways.

Each parameter to Machine() (or XML::SAX::Machine-new()>) represents one top level part of the machine. Each part has a name, a processor, and one or more handlers (usually specified by name, as shown in the SYNOPSIS).

Since SAX machines may be passed in as single top level parts, you can also create nested, complex machines ($filter3 in the SYNOPSIS could be a Pipeline, for example).

A SAX machines can act as a normal SAX processors by connecting them to other SAX processors:

my $w = My::Writer->new();
my $m = Machine( ...., { Handler => $w } );
my $g = My::Parser->new( Handler => $w );