Gource is an animated visualization tool for viewing GIT & CVS source repositories.

Andrew Caudwell’s “Gource” is an animated visualization tool for viewing GIT & CVS source repositories.

From the description:

Software projects are displayed by Gource as an animated tree with the root directory of the project at its centre. Directories appear as branches with files as leaves. Developers can be seen working on the tree at the times they contributed to the project.

Gource is an amazing program for visualizing commit history in a git-based code project. What I like about it is that it can also show what areas of the project are active in an easy to understand way, to show whether there is community around a whole project or just aspects of it. What looks like a shiny useless visualization is, in fact, pretty useful stuff. I’ll get to that in a bit.

So, I needed something to scan and past OSS things I’ve been involved with were logical first targets. To index the history on Cobbler into a concise video, I ran the following:

gource -s 0.03 --auto-skip-seconds 0.1 --file-idle-time 500 --max-files 500 --multi-sampling -1280x720 --stop-at-end   --output-ppm-stream - | ffmpeg -y -b 3000K -r 24 -f image2pipe -vcodec ppm -i - -vcodec mpeg4 gource.mp4

Want to run this yourself? You will likely have to build gource from source. I’ll warn you that building from source involves installing a ton of deps, though all are in Ubuntu 9.10, and once ./configure finally passes it does build fast. Fedora was downlevel with respect to ftgl, and compiling ftgl from source was difficult, hence the Ubuntu usage. The parameters I use above result in a large video (75MB) but are intended for YouTube HD.

The result is below. Note that I didn’t keep my source control commit attribution for the first couple of years on the project (lesson learned in how to use git!), I used to do development on devel and switched to master (this video shows master), and koan was grafted into the cobbler tree late in the game. Early on, I committed from two different user IDs. As a result, the video is not perfect — things tend to “pop” into view as releases happen. You’ll see the first outside attribution happen about 1/2 way through, though of course this was happening much much earlier. Still, the acceleration at the end, I think, means we achieved something pretty decent. Not all projects do.

Perhaps this is a start of a good meme. Get your code up on YouTube. Show us the life of your code and who you collaborate with.

I can see gource being immediately useful for a one major purpose. When evaluating OSS software for use in business, you always need to know if the community is solid and self sustaining. This allows you to watch a short video and find out. Coupled with looking through the mailing list archives, that’s a pretty good check. It can also help identify interesting patterns of large scale refactoring, new development, or stagnation.

Gource may also a great way to explain open source to people who don’t immediately understand how collaboration can work, and how contributors come and go.

That is what I call good TV. It is also rather trippy to look at. Please turn up the Floyd.

If we had a free supercomputer and infinite development time, my ultimate dream visualization would be a 20×20 foot wall section of these graphs, showing multiple projects side by side, with developers flying between projects. Who flies between projects? Is that common? What are the clustering patterns of these projects that share contributors? Where are the hubs and spokes? Are the hubs bigger projects than the spokes? (Can we get that in 3D?). There is something to be learned here, even if we don’t know what that is.
 

Download.

Screenshots.

The Linux Kernel.

A snapshot of a flurry of development on the Linux project.
As Linux is a huge C language project, the files being worked on are predominately a mix of .c (shown in green) and .h header files (in red).

 

Git SCM.

The Git SCM Project, one of the main version control systems supported by Gource.

Unlike many projects, most of the files of the Git project reside in several huge directories of hundreds of files, rather than being broken down into sub directories.

Git has a similar mix of colours to Linux as it is also written in C. The large orange directory contains .txt files (orange).

 

Papervision3D.

Papervision3D, a popular 3D library for Flash.

 

Blender.

Blender, a very popular free 3D graphics modeling and animation tool.

 

Custom Search

If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:

Flashbake: free version-control for writers using git.

For the past couple weeks, I've been working with Thomas "cmdln" Gideon (host of the fabulously nerdy Command Line podcast) on a free software project for writers called "Flashbake" (which is to say, I described what I wanted and Thomas wrote the code).

This is a set of Python scripts that check your hot files for changes every 15 minutes, and checks in any changed files to a local git repository. Git is a free "source control" program used by programmers to track changes to source-code, but it works equally well on any text file. If you write in a text-editor like I do, then Flashbake can keep track of your changes for you as you go.

I was prompted to do this after discussions with several digital archivists who complained that, prior to the computerized era, writers produced a series complete drafts on the way to publications, complete with erasures, annotations, and so on. These are archival gold, since they illuminate the creative process in a way that often reveals the hidden stories behind the books we care about. By contrast, many writers produce only a single (or a few) digital files that are modified right up to publication time, without any real systematic records of the interim states between the first bit of composition and the final draft.

Enter Flashbake. Every 15 minutes, Flashbake looks at any files that you ask it to check (I have it looking at all my fiction-in-progress, my todo list, my file of useful bits of information, and the completed electronic versions of my recent books), and records any changes made since the last check, annotating them with the current timezone on the system-clock, the weather in that timezone as fetched from Google, and the last three headlines with your by-line under them in your blog's RSS feed (I've been characterizing this as "Where am I, what's it like there, and what am I thinking about?"). It also records your computer's uptime. For a future version, I think it'd be fun to have the most recent three songs played by your music player.

The effect of this is to thoroughly -- exhaustively -- annotate the entire creative process, almost down to the keystroke level. Want to know what day you wrote a particular passage? Flashbake can tell you. Want to know what passage you wrote on a given day? That too. Plus, keeping track of my todo.txt file means that I get a searchable database of all the todo items I've ever used, with timestamps for their appearance and erasure.

Additionally, since git repositories are made to replicate, you can publish some or all of your projects to the public web or to a private site. I'm hoping that my publisher will use a public git repo to check out the most recent versions of my in-print books every time they go back to press for a new edition, and use the built-in compare ("diff") function to find all the typos I've fixed since the last edition.

It's all pretty nerdy, I admit. But if you're running some kind of Unix variant (I use Ubuntu Intrepid Ibex, but this'd probably do fine on a Mac with OS X, too) and you want to give it a whirl, Thomas has made all the scripts available as free software. He's working on a new version now with plugin support, which is exciting!

I love adapting programmers' tools for my writing. They tend to be extremely well-made and stable (because if they aren't, programmers will fix them or find better ones) -- it's like using chefs' knives in the kitchen.

Install.

Flashbake's installation and configuration documentation is already pretty complete, so I won't duplicate it here. In short, to run Flashbake, you'll need superuser access and the following installed as usual:

• Python with the setuptools module
• Git

Once you've laid that groundwork, download the latest version of Flashbake and extract it. In the extracted directory, run:

sudo python setup.py install

Now you're ready to start your project. Create a new folder—I called mine write—and cd into it. Then run:

git init

Make the first text file you're going to track with Flashbake, like my_novel.txt, and type a few lines. Now you're ready to start tracking its revisions with Flashbake. Create a new file in your project directory called .flashbake (don't forget the starting dot) and add the name of your text file to it. For example, my Flashbake project tracks two files, called my_novel.txt and this post in a file called flashbake_automates_version_control.txt. So the bottom of my .flashbake configuration file looks like this:

# "Hot files" for flashbake to commit, add yours here
my_novel.txt
flashbake_automates_version_control.txt

(Flashbake ignores the first line, which starts with the #, because it's a comment.)
Now we're almost ready to run Flashbake. First we've got to configure a plug-in or two.

Shake and Flashbake Plug-ins.

Flashbake plug-ins are the secret sauce that make it a worthy interface to Git. Plug-ins automatically add information to each version's commit notes, like feed items, the weather, and timezone.
Here's a full list of the default plug-ins that come with Flashbake. I used four plug-ins in my Flashbake project: weather, timezone, Twitter, and the feed plug-in. As the Flashbake plug-in documentation explains, list the plug-ins you want to use in your .flashbake file and its additional parameters below.


 Publish Your Flashbake Git Repository to GitHub.

Now you've got a local Git repository of file versions. Great, right? Well, not if you can use 'em easily. Git newbs don't know all the commands to search and diff between versions, but luckily a pretty web hosting solution for Git means you don't have to know the commands. I published my local Git repository to GitHub to show off my file changes in this post. Register for a free account at GitHub and create a new repository there. Then, push your local repository to GitHub for cloud backup and a good-looking web interface to your project. Use GitHub's setup instructions to do just that. After I created a repository on GitHub called write, GitHub told me to run the following commands (where "existing_git_repo" is your project directory):

The git push origin master command is the magical command that pushes your local files to GitHub. By default, you have to do that remote push by hand, but if you're automating Flashbake's runs, you can make local commits automatically push to a remote host (like GitHub) using this handy command.
Flashbake is still a very young mechanism for driving Git, and more plug-ins and configuration options are becoming available, so we've only scratched the surface here. But adopting programmer version control for writing, lists, or notes is something more and more tech-savvy folks will do going forward. Thanks to Leo Laporte and Cory Doctorow for making me aware of Flashbake in this episode of This Week in Tech.

Custom Search

If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:

Fossil simple, high-reliability, distributed software configuration management.

Fossil is a distributed version control system, bug tracking system and wiki software server for use in software development created by D. Richard Hipp.

Fossil is a cross-platform server that runs on Linux, Mac and Windows. It is capable of performing distributed version control, bug tracking, wiki services, and blogging. 

The software has a built-in web interface, which reduces project tracking complexity and promotes situational awareness. A user may simply type "fossil ui" from within any check-out and Fossil automatically opens the user's web browser in a page that gives detailed history and status information on that project.

Being distributed, Fossil requires no central server, although collaboration is made easier by using one.

Content is stored using a SQLite database so that transactions are atomic even if interrupted by a power loss or system crash.

Fossil is free software released under a BSD license[3] (previously GPL).

Fossil is used for version control by the SQLite project, which is itself a component of Fossil. SQLite transitioned to using Fossil for version control over CVS in September 2009.

Some examples of other projects using Fossil are:

• Pritlog
• Tcl/Tk Project

There are plenty of open-source version control systems available on the internet these days. What makes Fossil worthy of attention?

Why Use Fossil?

1. Bug Tracking And Wiki - In addition to doing distributed version control like Git and Mercurial, Fossil also supports distributed bug tracking, distributed wiki, and a distributed blog mechanism all in a single integrated package.

2. Web Interface - Fossil has a built-in and easy-to-use web interface that simplifies project tracking and promotes situational awareness. Simply type "fossil ui" from within any check-out and Fossil automatically opens your web browser in a page that gives detailed graphical history and status information on that project.

This entire website (except the download page) is just a running instance of Fossil. The pages you see here are all wiki or embedded documentation. When you clone Fossil from one of its self-hosting repositories, you get more than just source code - you get this entire website.

3. Autosync - Fossil supports "autosync" mode which helps to keep projects moving forward by reducing the amount of needless forking and merging often associated with distributed projects.

4. Self-Contained - Fossil is a single stand-alone executable that contains everything needed to do configuration management. Installation is trivial: simply download a precompiled binary for Linux, Mac, or Windows and put it on your $PATH. Easy-to-compile source code is available for users on other platforms. Fossil sources are also mostly self-contained, requiring only the "zlib" library and the standard C library to build.

5. Simple Networking - Fossil uses plain old HTTP (with proxy support) for all network communications, meaning that it works fine from behind restrictive firewalls. The protocol is bandwidth efficient to the point that Fossil can be used comfortably over a dial-up internet connection.

6. CGI Enabled - No server is required to use fossil. But a server does make collaboration easier. Fossil supports three different yet simple server configurations. The most popular is a 2-line CGI script. This is the approach used by the self-hosting fossil repositories.

7. Robust & Reliable - Fossil stores content using an enduring file format in an SQLite database so that transactions are atomic even if interrupted by a power loss or system crash. Furthermore, automatic self-checks verify that all aspects of the repository are consistent prior to each commit. In over three years of operation, no work has ever been lost after having been committed to a Fossil repository.

 

Links For Fossil Users:

• Testimonials from satisfied fossil users and Quotes about Fossil and other DVCSes.
• FAQ
• The concepts behind fossil
• Quick Start guide to using fossil
• Questions & Criticisms directed at fossil.
• Building And Installing
• Fossil supports embedded documentation that is versioned along with project source code.
• Fossil uses an enduring file format that is designed to be readable, searchable, and extensible by people not yet born.
• A tutorial on branching, what it means and how to do it using fossil.
• The automatic self-check mechanism helps insure project integrity.
• Fossil contains a built-in wiki.
• An Event is a special kind of wiki page associated with a point in time rather than a name.
• Settings control the behaviour of fossil.
• Use SSL to encrypt communication with the server.
• There is a mailing list (with publicly readable archives available for discussing fossil issues.
• Performance statistics taken from real-world projects hosted on fossil.
• How to delete content from a fossil repository.
• How Fossil does password management.
• Some (unfinished but expanding) extended reference documentation for the fossil command line.
• Documentation on the TH1 Script Language used to configure the ticketing subsystem.
• A free hosting server for Fossil repositories is available at http://chiselapp.com/.
• How to set up a server for your repository.
• Customizing the ticket system.
• Methods to identify a specific check-in.
• Import and export from and to Git.
• Fossil versus Git.

 

Links For Fossil Developer:

• Contributing code or documentation to the Fossil project.
• Thoughts On The Design Of Fossil.
• Principles Of Operation
• A Technical Overview Of Fossil.
• The file format used by every content file stored in the repository.
• The format of deltas used to efficiently store changes between file revisions.
• The encoder algorithm used to efficiently generate deltas.
• The synchronization protocol. 

 Download.

 Install. 

• Using A Pre-compiled Binary.

You can skip all of the following by downloading a pre-compiled binary appropriate for your platform and putting that self-contained binary someplace on your $PATH. To uninstall, simply delete the binary. To upgrade from an older release, just overwrite the older binary with the newer one.

• Executive Summary.

Building and installing is very simple. Three steps:

1. Download and unpack a source tarball or ZIP.
2. ./configure; make
3. Move or copy the resulting "fossil" executable to someplace on your $PATH.

Obtaining The Source Code.


Fossil is self-hosting, so you can obtain a ZIP archive containing a snapshot of the latest version directly from fossil's own fossil repository. Follow these steps:

1. Point your web browser at http://www.fossil-scm.org/. Click on the "Login" menu button.
2. Log in as anonymous. The password is shown on screen. The reason for requiring this login is to prevent spiders from walking the entire website, downloading ZIP archives of every historical version, and thereby soaking up all our bandwidth.
3. Click on the Timeline link at the top of the page.
4. Select a version of of fossil you want to download. Click on its link. Note that you must successfully log in as "anonymous" in step 1 above in order to see the link to the detailed version information.
5. Finally, click on one of the "Zip Archive" or "Tarball" links, according to your preference. These link will build a ZIP archive or a gzip-compressed tarball of the complete source code and download it to your browser.
   
   Compiling.

6. Unpack the ZIP or tarball you downloaded into that directory then cd into the directory created.
7. (Optional, unix only) Run ./configure to construct a makefile.
   
   1. If you do not have the OpenSSL library installed on your system, then add --with-openssl=none to omit the https functionality.
   2. To build a statically linked binary (suitable for use inside a chroot jail) add the --static option.
   3. Other configuration options can be seen by running ./configure --help
8. Run make to build the "fossil" or "fossil.exe" executable. The details depend on your platform and compiler.
   
   1. Unix → the configure-generated Makefile should work on all unix and unix-like systems. Simply type "make".
   2. Unix without running "configure" → if you prefer to avoid running configure, you can also use: make -f Makefile.classic. You may want to make minor edits to Makefile.classic to configure the build for your system.
   3. Msys/MinGW → Use the mingw makefile: "make -f win/Makefile.mingw"
   4. VC++ → Use the msc makefile. First change to the "win/" subdirectory ("cd win") then run "nmake /f Makefile.msc".

Note that Fossil requires the "zlib" compression library. This library is available by default on most unix systems, but it will typically have to be installed separately on windows systems. For windows builds, you may need to edit the makefile to tell it exactly where zlib is located on your system.

Installing.

9. The finished binary is named "fossil" (or "fossil.exe" on windows). Put this binary in a directory that is somewhere on your PATH environment variable. It does not matter where.
   
10. (Optional:) To uninstall, just delete the binary.
    
    
    Additional Considerations.
    

• If the makefiles that come with Fossil do not work for you, or for some other reason you want to know how to build Fossil manually, then refer to the Fossil Build Process document which describes in detail what the makefiles do behind the scenes. 

Custom Search

If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:

The cb2Bib is a free, open source, and multiplatform application for rapidly extracting unformatted.

The cb2Bib is a free, open source, and multiplatform application for rapidly extracting unformatted, or unstandardized bibliographic references from email alerts, journal Web pages, and PDF files.

The cb2Bib facilitates the capture of single references from unformatted and non standard sources. Output references are written in BibTeX. Article files can be easily linked and renamed by dragging them onto the cb2Bib window. Additionally, it permits editing and browsing BibTeX files, citing references, searching references and the full contents of the referenced documents, inserting bibliographic metadata to documents, and writing short notes that interrelate several references.
  
Advanced features.

Advanced features, and processing and extraction details are described in the following sections:

• Automatic Extraction: Questions and Answers
• Extracting data from the clipboard
• Processing of author's names
• Processing of journal names
• Field Recognition Rules
• Regular Expression Editor

Configuration information is described in the following sections:

• Configuration
• Predefined cite and document ID placeholders

Utilities and modules are described in the following sections:

• Search BibTeX files for references
• Embedded File Editor
• PDF Reference Import
• The cb2Bib Command Line
• Reading and writing bibliographic metadata
• The cb2Bib Annote
• The cb2Bib Citer

Requirements.
 

Compilation.

To compile cb2Bib, the following libraries must be present and accessible:

• Qt 4.4.0 or higher from Qt Nokia. On a Linux platform with Qt preinstalled, make sure that the devel packages and Qt tools are also present.

• WebKit library (optional) to compile cb2Bib Annote viewer. It is already included in Qt > 4.4.0 library. No special action/flag is needed during compilation.

• LZO 2.03 library and headers available at http://www.oberhumer.com/opensource/lzo. If LZO2 were unavailable on a particular platform, type configure --disable-lzo or, equivalently, qmake -config disable-lzo before compiling.

• X11 header files if compiling on Unix platforms. Concretely, headers X11/Xlib.h and X11/Xatom.h are needed.

• The header files fcntl.h and unistd.h from glibc-devel package are also required. Otherwise compilation will fail with referencelist.cpp:227: `::close' undeclared.

Deployment

Although not needed for running cb2Bib, the following tools extend cb2Bib applicability:

• jsMath, available at http://www.math.union.edu/~dpvc/jsMath, for displaying mathematical notation. Simply, download and unzip it in a desired directory.

• ExifTool, version 7.31 or later, available at http://www.sno.phy.queensu.ca/~phil/exiftool.

• pdftotext, found packaged as xpdf, and downloadable from http://www.foolabs.com/xpdf.

• The bib2xml and xml2end BibUtils, to test the postprocess script bib2end.bat on Windows platforms.

• ... and LaTeX and friends, to check for BibTeX file correctness and to get a nice printing through the shell script bib2pdf.

Current version: cb2Bib 1.4.6. (See ChangeLog File for a detailed list of changes and acknowledgments, and Release Notes for additional notes and information.).


Download.



 Screenshots.

Custom Search

If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:

Virtual MIDI Piano Keyboard (VMPK) is a MIDI events generator and receiver.

Virtual MIDI Piano Keyboard is a MIDI events generator and receiver.

It doesn't produce any sound by itself, but can be used to drive a MIDI synthesizer (either hardware or software, internal or external).

You can use the computer's keyboard to play MIDI notes, and also the mouse.

You can use the Virtual MIDI Piano Keyboard to display the played MIDI notes from another instrument or MIDI file player.

To do so, connect the other MIDI port to the input port of VMPK.

VMPK has been tested in Linux, but maybe you can build it also in other systems.

The Virtual Keyboard by Takashi Iway (vkeybd) has been the inspiration for this one. It is a wonderful piece of software and has served us well for many years.

VMPK uses a modern GUI framework: Qt4, that gives excellent features and performance. RtMIDI provides MIDI input/output features. Both frameworks are free and platform independent, available for Linux, Windows and Mac OSX.

The alphanumeric keyboard mapping can be configured from inside the program using the GUI interface, and the settings are stored in XML files. Some maps for Spanish, German and French keyboard layouts are provided, translated from the ones provided by VKeybd.

VMPK can send program changes and controllers to a MIDI synth. The definitions for different standards and devices can be provided as .INS files, the same format used by QTractor and TSE3. It was developed by Cakewalk and used also in Sonar.

This software is in a very early alpha stage. See the TODO file for a list of pending features. Please feel free to contact the author to ask questions, report bugs, and propose new features. You can use the tracking system at SourceForge project site.

Virtual MIDI Piano Keyboard is free software licensed under the terms of the GPL v3 license.

Getting started.

MIDI concepts.

MIDI is an industry standard to connect musical instruments. It is based on transmitting the actions performed by a musician playing some instrument to another different instrument.  Musical instruments enabled with MIDI interfaces typically have two DIN sockets labeled MIDI IN and MIDI OUT.

Sometimes there is a third socket labeled MIDI THRU.  To connect a MIDI instrument to another one, you need a MIDI cable attached to the MIDI OUT socket of the sending instrument, and to the MIDI IN of the receiving one. You can find more information and tutorials like this one all around the Net.

There are also hardware MIDI interfaces for computers, providing MIDI IN and OUT ports, where you can attach MIDI cables to communicate the computer with external MIDI instruments. Without needing hardware interfaces, the computer can also use MIDI software. An example is VMPK, which provides MIDI IN and OUT ports. You can attach virtual MIDI cables to the VMPK's ports, to connect the program to other programs or to the computer's physical MIDI interface ports.  More details about this coming later. You usually want to connect the MIDI output from VMPK to the input of some synthesizer which transforms MIDI into sound. Another common destination for the connection would be a MIDI monitor that translates MIDI events into readable text. This will help you to understand what kind of information is transmitted using the MIDI protocol. In Linux you can try KMidimon and in Windows MIDIOX.

VMPK doesn't produce any sound. You need a MIDI software synthesizer to hear the played notes. I recommend you to try QSynth, a graphical front-end to Fluidsynth. It is also possible to use the "Microsoft GS Wavetable SW Synth" that comes with XP. Of course, an external MIDI hardware synth would be an even better approach.

Keyboard maps and instrument definitions.

VMPK can help you to change sounds in your MIDI synthesizer, but only if you provide a definition for the synthesizer sounds first. The definitions are text files with the .INS extension, and the same format used by Qtractor (Linux).

When you start VMPK the first time, you should open the Preferences dialog and choose a definition file, and then select the instrument name among those provided by the definitions file. There should be one instrument definitions file installed in the VMPK's data directory (typically "/usr/share/vmpk" in Linux, and "C:\Program Files\VMPK" in Windows) named "gmgsxg.ins", containing definitions for the General MIDI, Roland GS and Yamaha XG standards. It is a very simple format, and you can use any text editor to look, change, and create a new one.

You can find a library of instruments definitions at the cakewalk ftp server.

Since the release 0.2.5 you can also import Sound Font files (in .SF2 or DLS formats) as instruments definitions, using a dialog available at menu File->Import SoundFont.

Another customization that you may want to tweak is the keyboard mapping. The default layout maps about two and half octaves for the QWERTY alphanumeric keyboard, but there are some more definitions in the data directory, adapted for other international layouts. You can even define your own mapping using a dialog box available in the Edit->Keyboard map menu. There are also options to load and save the maps as XML files.

The last loaded map will be remembered the next time you start VMPK. In fact, all your preferences, selected MIDI bank and program, and the controller values will be saved on exit, and restored when you restart VMPK the next time.

MIDI connections and virtual MIDI cables

To connect hardware MIDI devices you need physical MIDI cables. To connect MIDI software you need virtual cables. In Windows you can use some virtual MIDI cable software, like MIDI Yoke, Maple, LoopBe1 or Sony Virtual MIDI Router.

MIDI Yoke setup process will install the driver and a control panel applet to change the number of MIDI ports that will be available (you need to restart the computer after changing this setting). MIDI Yoke works sending every MIDI event written to an OUT port to the corresponding IN port. For instance, VMPK can connect the output to the port 1, and another program like QSynth can read the same events from the port 1.

Using MIDIOX you can add more routes between MIDI Yoke ports and other system MIDI ports. This program also provides other interesting functionalities, like a MIDI file player. You can listen the songs played in a MIDI Synth and at the same time see the played notes (only one channel at a time) in VMPK. To do so, you can use the "Routes" window in MIDIOX to connect the input port 1 to the Windows Synth port. Also, configure the player's MIDI port to send to MIDI Yoke 1. And configure VMPK Input port to read from MIDI Yoke 1. The player will send the events to the out port 1, which will be routed to both the input port 1 and at the same time to the synth port.

In Linux, you have ALSA sequencer to provide the virtual cables. The ports are dynamically created when you start a program, so there is not a fixed number of them like in MIDI Yoke. The command line utility "aconnect" allows to connect and disconnect the virtual MIDI cables between any ports, being hardware interfaces or applications.

A nice GUI utility for doing the same is QJackCtl. The main purpose of this program is to control the Jack daemon (start, stop and monitor the state). Jack provides virtual audio cables to connect your sound card ports and audio programs, in a similar way to the MIDI virtual cables, but for digital audio data.

Screenshots.

Custom Search

If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog: