Here is my latest music, a classical piece composed and performed by my Meander module in A-Mixolydian with a I-IV-V first order Markov chain harmonic progression. Voices are via 7 HOSTS playing Spitfire Audio BBC Symphony Strings VST voices.
As usual, there are several sequencers sequencing sequencers here.
In a continuation of my classical music compositions and explorations, here is THE most famous canon, composed by Pachelbel in the 1600s for three violins. I started in Meander with the â#25 Canon - DMajâ harmonic progression preset and Meander creates the canon like structure using 10 voices of the Spitfire Audio BBC Symphony Orchestra VST plugin strings voices via 7 HOST modules.
There are several sequencers sequencing sequencers here, as well as sequencers sequencing Meander parameter CV inputs control.
Here is my latest piece âA World in Perfect Harmonyâ in Db-Major. Generated by Meander and played by SquinkyLabs Organs3, HOST Arturia Piano V VST, HOST Labs 64 Spitfire Audio Choir VST. 14 tracks. Using Meander Harmony preset #31, Markov Chain-Bach 1. This uses a Markov chain using a first order transition matrix based on Bachâs most common chord transition probabilities. Db-Major is one of Bachâs favorite keys.
PurrSoftwareâs Meander plugin/module V2.0.20 is now in the library. This release is primarily about Harmony Chords âProgression Presets #4:customâ editing and saving the info within the patch via JSON data.
See the release notes (changelog) and the manual for more details. The current manualâs progression editing section is still valid, but I will be expanding this section a bit, probably today. The main thing to remember is that once you get your custom progression as you want it, DO NOT switch to another âProgression Presetâ in that patch Meander instance or your customization will be lost. If you want to be able to see available progressions to use as starting points on your custom progression, add a 2nd instance of Meander to the patch. You can later remove this second instance from the patch, if you wish.
Here is an example screen grab of the simplest setup for using a custom harmonic progress in one instance of Meander while having a second instance in the patch just to get ideas for a custom progression.
Bonus example: This patch also shows how to create a 4-voice harmony chord structure rather than or in addition to the Meander 3 note triad chords. This technique just takes the root or tonic note of the chord which is always in the first channel and adds the tonic raised by an octave (1V added to the note) to the polyphonic chord. This still works with 7th-chords, but the 7th note will be replaced by the tonic octave note. If you want, you could use one of the other notes of the triad raised an octave. There are many ways to do this, this example is just the simplest.
Here is the revised manual section for creating and editing custom harmonic (chord) progressions of from 1 to 16 steps.
#4 Custom progression preset editing (New in V2.0.20)
A best practice is to set up a new patch or save an existing patch as a new name and then do your custom editing and use in that patch and never touch the Progression Presets knob in that instance of Meander in the patch. Note, you can have multiple instances of Meander in a patch and each instance can have its own custom harmonic progression.
I took a look at Meander this morning. I know that panel is getting pretty packed, but the visual alignment of the graphic elements could be improved I think. Especially in the left hand area, both vertical and horizontal alignment is pretty haphazard. Also some elements touch each other or even overlap. It looks like the yellow text boxes have a little more rounding on the corners than the back output jack backgrounds? Also, the font used to display scale notes is bigger and bolder than almost any other found used in the UI.
Yep, I focus on functionality rather than on aesthetics, so there is always room for improvement of the GUI. Thanks for your suggestions.
By the way, a big issue is that I use nanoVG for all of the panel, rather than SVG. Unfortunately, nanoVG does some strange font scaling dependent on Rack zoom setting. Some things I have picked as a compromise that looks reasonable at all zooms, although it cannot look identical without tweaking the font size dynamically with zoom level. The side effect of this is sometimes text runs into something at some zoom settings. Believe it or not, I consciously tweaked the font and sizes based on some rational criteria, but that is very specific to my goals than to aesthetics.
The recent issue with font licenses definitely had some adverse effects on the uniformity of my panel, but then it wasnât great beforehand.
An example is the scale notes below the mode selection and description text. This is not a label but rather a display. I played around a lot with it, believe it or not.
If anyone has any tricks on how to dynamically adjust font sizing as a function of zoom level, I am interested and will take that into consideration.
Oh, interesting. I havenât paid much attention to that font/zoom issue. Iâm not super surprised, in theory, as fonts have âhintsâ on other weird things to make them look âbetterâ at some sizes. Just saying it might not be nano-vg in particular - might happen with other apps, too. But donât really know.
Yeah, when I made modules I just didnât have to talent / inspiration to make them look âgoodâ. I didnât really like it when ppl said âoh, I never use your modules, I think they are uglyâ.
I think everyone is different. To me, I donât mind plain visuals. In my own stuff or other peoples. I do hate bad alignment, and do have the tools to see and fix that. So I think I rarely put out something with those kind of visual âflawsâ.
But a great thing about free software is that you can make whatever you want, and donât really have to worry about otherâs reactions, especially ones you donât care about.
So, cool.
Yeah, it is probably Rack rather than nanoVG, or a combination of both.
I could always be a smartass and say that the text alignment issues is just a matter of Meander for VCV Rack being true to Meander for Windows 
As mentioned elsewhere, I began Meander as a DOS app in 1988. In 1992 I started seriously developing for Windows with version 3.1 and Windows for Workgroups. As I thought this Windows thing was really going to take off, I bought a significant amount of MS stock. When I sold it several years later, the price had gone up by 25x!
I last built Meander for Windows 98 in 2002 and made it a 16-bit app (I think). I last built it in 2016 as a 32-bit app for Windows XP(?).
To make a long story short, Meander works great under Win11 but the text does weird things and sometime is off-window.
But, it amazes me that my 30 year old Meander for Windows still works fine.
But, the Meander for VCV Rack is considerably better than any version prior.
Yeah, I was a little surprised, but that text moving around does seem to be nano-vg, or whatever it uses for text layout. I see that in other rendered text, like in some of my modules, but I donât see it in other apps. I wonder if itâs just some dumb rounding error?
One last thing on this, unless someone can point out how to correct this NVG font zoom scaling issue:
The existing last several releases of Meander attempt to make the text scaling and alignment look the best when zoomed in at maximum magnification, as that seems more important than having alignment optimized for the maximum zoomed out minimum magnification, or even at 100% zoom magnification.
One thing I am concerned about is my usage of:
nvgTextLetterSpacing(args.vg, -1);
As always, it is difficult to find thorough documentation on NVG. Is my use of â-1â causing problems?
I donât think itâs anything you are doing. Look at any other module that renders text. VCV Notes is a good example. They all do the same thing. Now that I know about it, I consider that a bug in nano-vg.
Of course this is another reason that putting static text into the SVG is often a good way to go.
You sure about that? One of the only places in VCV Rack V2 that uses ngvTextLetterSpacing() is in Audio.cpp and in that case passes a 0.0 as the last argument rather than -1. My Fundamentals plugin source is from January and it does not show Notes calling this function. In scope.cpp, the function is called with the last argument being -2.
I donât see anything wrong with your use of the letter spacing.
The documentation is very clear that glyph placement is always snapped to provide sharp pixel alignment. Which will cause text to shuffle around a little at different zooms.
Which documentation is that? I may have missed it or forgotten about it.
Thanks. I did overlook that section in the file this morning. Seems like I am doing things correctly. Just to be clear, my text is not shuffling around at the pixel level but maybe by ten(s) pixels, but maybe it is difficult to know just what I should expect in terms of screen pixels at high zoom.
I agree, it looks wrong. And in all apps.