Polymeter 0.0.23 adds graphing capability

Polymeter 0.0.23 introduces graphing, to help you visualize your modulations. The heavy lifting of generating the graph is done by Graphviz, an excellent free software that's used in many projects including Doxygen. The scope of the graph can be one of these:

Scope	Description
All	Show all modulations regardless of track selection
Selected	Show direct modulators of selected tracks
Recursive	Show direct and indirect modulators of selected tracks
Bidirectional	Show direct and indirect modulators and modulatees of selected tracks

Various graph layouts are supported, including dot(for heirarchical graphs) and neato (for relational graphs). The edges are colored to indicate modulation type, and edge labels can optionally be displayed. The graph is generated as vectors (SVG format) so it's zoomable, and can be exported for printing. Hovering over a node's label shows a tooltip containing the track number. The graph is displayed using a web browser control (IWebBrowser2). Note that the recommended Internet Explorer version is 11 or later (Edge); earlier versions of IE may display the graph incorrectly or not at all.

This version also features a MIDI input bar that lists MIDI input events with filtering options.

Polymeter 0.0.21 adds MIDI Output and Piano bars

Polymeter 0.0.21 adds two dynamic visualizations that can help you grasp what you're hearing: a MIDI output bar that shows the output MIDI events as text, with filtering options, and a piano bar that displays the output notes on a piano keyboard, also with filtering. Both of these visualizations were proposed in a previous post.

The main issue with implementing visualizations is a multithreaded design problem, which stems from the fact that the sequencer runs in a different thread from the rest of the application (the sequencer callback thread). In order to safely transfer data from one thread to another, serialization is required, but the goal is to minimize the likelihood of the sequencer callback thread ever being blocked by the user interface thread. The most appropriate and performant architecture for this situation is a buffer swapping scheme. In order to reduce time spent in the critical section to the absolute minimum, only pointers to the buffers are exchanged, rather than the buffers themselves. Fortunately the dynamic array class already supports swapping buffer pointers with another array instance. The result is the best of both worlds: zero-copy exchange between a pair of growable arrays.

This version also adds a command to reset the window layout to defaults. Thanks to Benoit Ruelle for suggesting this useful feature.

Polymeter visualization ideas

Writing in polymeter can be very complicated. Often it's hard to visualize how all the patterns and modulators are interacting with each other to create the music. It might help if the software including more and better visualizations. Here's a list of visualization ideas I'm thinking about.

The core problem is that our ears are amazingly good at integrating multidimensional information in real time, whereas our eyes, not so much. People can comprehend a complex piece of music even at a fast tempo, but if that same piece is modeled visually it just looks like a blur. That's partly because vision processing is relatively slow compared to hearing, but mostly because the brain evolved to handle the demands of language and thus can easily process pitches, rhythm, and timbre all once in real time.

Polymeter visualization ideas

Modulation graph. Display a “boxes and arrows” type graph that captures the song’s modulations, including all tracks that are participating in modulation, connected by arrows that show the direction and type of the modulation. The graph would be dynamic in the sense that updating the document would automatically redraw the graph if necessary. The drawing could be done using GraphViz for example, as I did for the FFRend project. The user would have to install GraphViz for this feature to work, so the feature would have to be optional. Implementation would be fairly easy since GraphViz does all the heavy lifting.

Active modulation list. Display a table that shows each modulated parameter and its current state. Since modulation type is currently limited to mute, note, velocity, and duration, only these properties would need to be shown, and only for tracks that are modulated. Thus the table could have five columns (track name, plus one for each modulation type), and there could be one row for each track that’s modulated. The table would update dynamically while the song is playing, allowing the user to visualize the modulation state and how it corresponds to the audio output. This idea only works during playback. One issue is that for complex songs with many tracks, it won’t be possible to see the entire modulation state at once, because the table will be too long to fit on the screen without scrolling. The biggest challenge would be keeping the table adequately synchronized with the audio output. This view could also incorporate the song dubs, but at the cost of showing every track, not only the modulated ones.

Piano roll. Display a dynamic piano roll view of the sequencer’s output for a specified MIDI channel. The view would take all modulations into account, allowing the user to visualize the cumulative effect of modulations on an instrument. The main limitation is that it would only work for notes, and only for one channel at a time. A visualization for controllers would have to be implemented separately. The view could scroll automatically while the song is playing, but one disadvantage of this is that at fast tempos the data may scroll too quickly to be comprehensible, though this wouldn’t be an issue when playback is stopped. This idea would be fairly easy to implement since it’s non-interactive, unlike piano roll editing which is much harder.

Piano keyboard. Display a dynamic piano keyboard that shows the sequencer’s output for a specified MIDI channel, or for all channels. The view would take all modulations into account, allowing the user to visualize the cumulative effect of modulations. The main limitation is that it would only work for notes; controllers wouldn’t be shown. Unlike the piano roll view described above, the piano keyboard would only work during playback. Showing all channels at once will be less effective if the parts on the different channels have overlapping ranges. Implementation would be fairly easy since much of the code could be reused from the ChordEase project, though again synchronization may be problematic. Performance impact depends on whether the event data is obtained from the sequencer callback, or recreated. Recreating the data is more complex, but safer as it avoids multithreading problems.

MIDI dump. Display a dynamic list of all output MIDI events, or only those for a specified channel. The main limitations are that it would only work during playback, and in many cases the information will scroll too fast to be useful. The latter issue can be addressed by implementing filtering by event type. Some of the code could be reused from the ChordEase project.

Polymeter 0.0.17 adds recursive modulation

Version 0.0.17 of Polymeter introduces a powerful new feature called recursive modulation, also known as modulation of modulation, or N-order modulation. For example, suppose you have a note track, and want its note to be modulated differently at different times. You could create two different modulator tracks, both modulating the note, and alternate between them by manually muting and unmuting them. But what if you want to automate the alternation? Now you can, by creating a mute modulator for each of your note modulators. If the two mute modulators have opposite step patterns, the result is that the two note modulators alternate, just as if you were alternating them by hand.

The key point is that you can now create multilevel hierarchies of mute modulation, whereas before modulation was essentially flat, with only one level possible. The hierarchy is limited to 32 levels, but this should be more than adequate. It’s possible to create an infinite recursion, but the application detects this and displays an error message.

Version 0.0.11 adds Live view functionality including per-part progress bars.

Version 0.0.11 adds functionality to the Live view, including per-part progress bars. The purpose of the bars is to indicate your current position within each part. This is problematic because a part can (and often does) consist of multiple tracks, each of which may have a different loop length. A progress bar requires a single length, so it shows the current position in the part's longest track. It's simple and consistent and much better than flying blind.

Polymeter 0.0.09 adds live performance view, inter-track modulation; port nearly complete

Polymeter 0.0.09 adds a live performance view, along with the ability to group tracks into parts, in order to simplify the interface. With this addition, the port is mostly complete. All of the three separate DOS programs that comprised the original software are now combined into a single Windows application: Bongo became Track view, Stencil became Song view, and Jock became Live view.

Polymeter 0.0.09 also adds inter-track modulation, an essential feature that allows a track in one meter to mute and unmute one or more tracks in other meters. Unlike the original software, which only supported mute modulation, the new sofware also supports note, velocity, and duration modulation. In note modulation, one track offsets another track's note values; velocity and duration modulation work similarly.

Polymeter 0.0.08 added presets, which let you save and restore the state of all the track mutes. This is very helpful for transitioning seamlessly between the sections of a song during a live performance.
The software is now hosted at both SourceForge AND GitHub.

https://polymeter.sourceforge.io/
https://victimofleisure.github.io/Polymeter/

Polymeter 0.0.07 released, introduces song view (AKA Stencil)

Polymeter 0.0.07 is a major release, and introduces song view, which lets you arrange your tracks on a conventional timeline. The idea is that you can "paint" with your polymeter loops, and be confident that regardless of how they're dubbed in and out, their phase relationships will always be preserved; in other words, your tracks stay synchronized through all your transitions, just as if they had been playing continuously from the start of the song. And what a difference that makes!

There are least two scenarios. You can either create your arrangement from scratch in song view, or you can record a rough live mix, and then use song view to refine your dubs. In the original DOS software, song view required a whole separate app (called Stencil), but today it's just another view. The first screenshot below shows song view.

This version also includes many UI enhancements: General MIDI patch and drum names can optionally be displayed instead of numbers, popup edit controls and drop lists now affect the sequencer's output immediately, column widths and order and splitter bar positions are persistent, etc.