Free methods machine 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.

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 );

Visual Turing Machine project is a program that lets you create Turing machines with a point and click interface instead of using esoteric languages.
You can pack your complex machines into small boxes, and then reuse them as part of a bigger machine. VTM also features an infinite length tape.
Enhancements:
- New features include an n-ary set of symbols, multiple windows (MDI), a huge workspace (10000x10000 pixels) without a memory issue, the ability to edit your own machines, the ability to execute machines n times (where n is undefined), the ability to use expressions (like n+5) to execute machines, the ability to execute machines at desired speeds, statistics to see how many instructions were executed and how much tape was "used", and an easy wasy to translate the program to other languages.

Yet Another Machine Simulator is a machine simulator which emulates the MIPS32 architecture CPU close enough. Should be fully compliant, but we cant claim that it is. It allows cross compilation with standard MIPS32 compiler back-ends.
YAMS also provides a very simple device interface to the simulated memory, disks, network interfaces, terminals and a real-time clock. There is also support for pluggable I/O devices. Pluggable devices are separate programs that implement the functionality of one or more devices and communicate with YAMS over a network or Unix domain socket.
Many features of YAMS are configurable. For example the number of CPUs can be configured. When the number of CPUs is more than one, YAMS simulates an SMP machine. The devices are also configurable. For example various delays for disks, terminals and network interfaces can be set.
YAMS also provides a hardware console which can be used to debug programs. The hardware console can be used to set breakpoints and dump the contents of registers, TLBs and memory. The memory dumping functionality also contains a disassembler.
Performanc:
The purpose of YAMS is to provide a very simple yet realistic simulated hardware platform for educational purposes. High performace (i.e. high clock speed) was not a factor in its implementation, so a normal slowdown factor between host clock speed and simulator clock speed is in the order of 500, resulting in simulator clock speeds of only a few megaherz.
So if you are looking for a fast MIPS emulator/simulator, then YAMS is not for you.
Enhancements:
- Better portability with pthreads and printf formatting macros.
- Minor bugfixes.

Virtual Machine Manager software (virt-manager for short package name) is a desktop user interface for managing virtual machines. The project presents a summary view of running domains and their live performance & resource utilization statistics. A detailed view presents graphs showing performance & utilization over time. Ultimately it will allow creation of new domains, and configuration & adjustment of a domains resource allocation & virtual hardware. Finally an embedded VNC client viewer presents a full graphical console to the guest domain.

The application logic is written in Python, while the UI is constructed with Glade and GTK+, based on mockups provided by UI interaction designers. The libvirt Python bindings are used to interacting with the underlying hypervisor. This enables the application to be written independant of any particular hypervisor technology. Initially Xen was the primary platform supported, however, since libvirt 0.2.0 and virt-manager 0.3.1 it is possible to manage QEMU and KVM guests too. It is expected that support for additional hypervisors / virtualization products will expand even further over time as additional libvirt drivers are written.
The "Virt Install" tool (virtinst for short package name) is a command line tool which provides an easy way to provision operating systems into virtual machines. It also provides an API to the virt-manager application for its graphical VM creation wizard.

The "Virt Clone" tool (virtinst for short package name) is a command line tool for cloning existing inactive guests. It copies the disk images, and defines a config with new name, UUID and MAC address pointing to the copied disks.
The "Virtual Machine Viewer" application (virt-viewer for short package name) is a lightweight interface for interacting with the graphical display of virtualized guest OS. It uses GTK-VNC as its display capability, and libvirt to lookup the VNC server details associated with the guest. It is intended as a replacement for the traditional vncviewer client, since the latter does not support SSL/TLS encryption of x509 certificate authentication.

C# Java Virtual Machine is a tiny implementation of the Java VM, including simple native classes. This project is written using the C# language. The VM is very easily expandable by writing additional native or Java classes.
Enhancements:
- The DbConnection class, which provides a connection to MS SQL or PostgreSQL using ADO.NET, was added.
- The Syst.MachineName method, which returns the machine name, was added.
- String.startsWith and String.endsWith functions were added.
- Some comments for VM.cs were written.