Release Candidate

VMPC2000XL v0.9.0 release candidate 16

Changes:

Fix random crashes when hitting pads. It seems iPadOS users were most affected by this bug, but it may well have affected users on other platforms.
Fix sound preview when hitting pads in the TRIM/LOOP/ZONE screens. VMPC2000XL used to play whatever sound is assigned to the pad you hit, but this behaviour is incongruent with the real MPC2000XL. It should play the selected sound, regardless of which pad you hit.
Allow MIDI control presets to specify a value for the CC mappings. See https://vmpcdocs.izmar.nl/0.9.0.0/vmpc_specific.html#midi-control.
Add a bundled MIDI control preset for Akai MPC Studio.
Add a demo beat called "TRAIN" because the author of VMPC2000XL made this a while ago while traveling by train.
Set correct 'Loop to' value after recording a new sound.
Set correct 'St', 'End' and 'Loop to' after resampling.
Fix saving and loading of LOOP information of a Song.
Fix an issue with the initial new name when changing the name of a sound.
Don't reset new sample rate in the Resample screen after changing the new name.
Fix an issue with the playback pitch of sounds after having changed the audio engine or host's sample rate.
Fix audio input/output device selection bug. Sometimes when changing the input device, the output device would also be changed, and vice versa.
[Windows] Statically linked CRT. This means that it's not necessary anymore to install a Visual C++ Redistributable to make VMPC2000XL work on older systems.
[Windows 32 bit] Fix VST3 and LV2 installation path. The installer used to place these files in "C:\Program Files (x86)\Common Files\", which is incorrect. They should be placed in "C:\Program Files\Common Files\".

VMPC2000XL v0.9.0 release candidate 12

Changes:

Fix crash in slider Assign screen when hitting a pad in bank B, C or D.
Fix 16 LEVELS handling of pads in bank B, C or D.
Fix issues with recording note events while the sequencer is not running. Quite a few users may already know that note events can be recorded in the Step Editor, by hitting one or more of the pads. A metronome will start playing, and by default the actual duration of how long the pad is pressed is assigned to the note event's duration. Another feature of the real MPC2000XL is that you can achieve the same, but in the Main screen. To do this, you have to hit pads while holding the REC button. Both of these features were not working well in VMPC2000XL, but now they should be fixed.
Fix an issue with assigning values in the VMPC2000XL-specific MIDI screen. Note and CC values were wrapping around to their lowest possible value if you would attempt to increase them beyond their highest possible value.

VMPC2000XL v0.9.0 release candidate 11

Changes:

[plugin] Fix crash on Intel Mac in Reaper with certain output configurations.
Fix go-to-previous/next-event. This used to work fine, but in v0.9.0.4 a regression was introduced. Now it works like it should again.

VMPC2000XL v0.9.0 release candidate 9

Changes:

[plugin] Ensure buffers are cleared after plugin is opened. There was an issue in Reaper, and quite possibly in other hosts too, where right after opening VMPC2000XL, the multi-channel tracks were muted because the signal contained absurdly high amplitude values. This happens if a buffer is not properly cleared. This bug is now fixed.

VMPC2000XL v0.9.0 release candidate 8

For this release I've received a lot of super valuable input from various users and contributors. A big warm thank-you to them!

[plugin] Implement musical position synchronization to the DAW. Wherever you place the play head in your DAW, VMPC2000XL positions its internal sequencer reasonably. Most likely this only works as expected if VMPC2000XL uses the same time signature as the DAW, and neither VMPC2000XL or the DAW vary the time signature anywhere in the arrangement.
[plugin] The DAW's play head can be repositioned while playing, and VMPC2000XL follows.
[plugin] Fix synchronization with Cubase. In earlier versions of VMPC2000XL this wasn't working at all.
[plugin] VMPC2000XL now also supports synchronizing to the DAW in Song mode.
[standalone] Fix individual outputs. v0.9.0.0 introduced a regression due to the complete rewrite of multibus support. This has been fixed.
Fix conflict between ordinary typing and typing via the pads in the Name screen.
Make ordinary typing configurable. See Shift + 0 for VMPC2000XL-specific settings. If Name typing w. keybd is set to NO, you can only enter names via the cursor keys and DATA wheel, or via the pads.
Fix small cosmetic bug when using the slider in the TRIM screen to change the End value.
Hide unused fields in the timestretch functionality. Timestretch in VMPC2000XL isn't nearly as good and complete as the MPC2000XL's timestretch, in particular because it doesn't implement the Preset and Adjust fields. Previously, VMPC2000XL was showing these fields, even though they are ignored by the timestretch algorithm. This is very misleading, and it probably has wasted precious time of users who would keep trying to timestretch with different settings that didn't actually make a difference in the result.
Allow the Open Window key to close the opened window, just like on the real MPC2000XL.

VMPC2000XL v0.9.0 release candidate 4

Fix slider UI updates when moving the slider via MIDI.
Fix Song mode DAW synchronization.
In the Mixer screens, holding down SHIFT and tapping the drum pads, allows you to select multiple channels simultaneously. This is an official MPC2000XL feature that was missing all these years.
Fix various multi-bus issues with the VST3 version. The issues were noticed in Reaper, but it's possible other hosts had issues too. The wrong audio was sent to the wrong bus, and after changing the individual output of a pad, there was noise in the buffer. Additionally in Reaper many of the additional buses would at times be muted after opening the plugin. Also the initial channel configuration in Reaper was incorrect.
Follow DAW tempo, even when the DAW is not playing.
Fix iOS Bluetooth MIDI permissions.
Show the disclaimer only once. It was showing every time you opened the GUI in some hosts for some plugin formats.

VMPC2000XL v0.9.0 release candidate 0

_images/vmpc2000xl-full-gui-screenshot.jpg
Highlights:

Completely new UI based on vector graphics
Improved multi-bus plugin support
LV2 for macOS and Windows

The manual for the release candidate is here: https://vmpcdocs.izmar.nl/0.9.0.0

If you're interested in the story behind this release, continue reading. If not, enjoy the release candidate, and please report problems via https://izmar.nl/support/bug-reports-feature-requests

New UI

The previous UI was based on bitmaps. A bitmap describes an image as a 2-dimensional grid of cells, where a color value for each cell is provided. Microsoft's BMP files work like this, as does PNG and many other image formats. I took a photo (which is a bitmap) of my MPC2000XL with my phone, and I modelled the animating components -- DATA wheel, slider and pot caps -- in Blender (which renders to bitmaps).

This looked ok, but I wanted the LCD to take up much of the free surface that surrounds the original, in order to make the LCD easier to read and use. With a photo, it's not very natural to make this kind of change -- enlarging the display implies losing detail, and the enlarged display needs to blend in well with its new surroundings. As to blending in well; that also applies to the function keys that need to be repositioned. The result has never been very pretty or neat, but it worked.

In comes the new UI, using vector graphics to display the virtual MPC2000XL. If you've ever seen SVG files or seen someone work in Adobe Illustrator, you have seen vector graphics. Here, we describe not a range of pixels, but we describe an image in terms of geometrical shapes with certain positions, colors, line widths, and so on. One of the advantages is that it's very natural for such images to be decomposed and rearranged.

Vector graphics are nice to have when using VMPC2000XL on the desktop, because it also happens to deliver a pretty clean and decent UI compared to a gritty photo with wonky Blender stuff (100% my fault, not Blender's). But in the back of my head, one reason I always really wanted vector graphics, was to improve the iOS version that is currently in TestFlight. At the moment you can only run VMPC2000XL on iPads, because iPhones are too small for the UI. The buttons get too finicky, end of story. But there's a fair chance of having at least some utility on smaller devices if there would be different views instead of a single UI, where each view is only a few of all possible UI components.

So, when I got an email from someone saying his friend could make MPC2000XL vector art, I immediately jumped on the opportunity. I wowed out loud when I got the email with the bitmap preview, and when I finally received the vector art source file and zoomed in on all its lushness, I couldn't wait to get busy and integrate it into VMPC2000XL.

The process of reworking raw vector art for using it in an application with many interactable components was quite challenging and required a lot of patience and trial and error, while, in parallel, coming up with a kind of "engine" of sorts that would be running inside VMPC2000XL, as well as coming with a file format for that engine. The engine had to take fairly human-readable files that describe a view, or an arrangement of components, and convert that to the kind of C++ code that is necessary for actually drawing stuff onto the screen. I decided to use JSON files for this. Here's a quick actual example:


{ "name" : "cursor_keys", "shadow_size" : 1, "svg" : "cursor_keys.svg", "label" : "CURSOR" }

This will draw the cursor_keys.svg file with the text "CURSOR" above it, with a nice little shadow effect. Everything together is grouped into a component with the name "cursor_keys".

Although some may prefer bitmap aesthetics and editing, this way of describing and composing UI elements gives a lot of versatility, and allows for reusable sub-arrangements, like the pads section, or the function keys and display. It's also a great foundation for custom VMPC2000XL interfaces, or skins. Those who aspire to create skins are encouraged to play with what is currently available. On macOS you can directly start by tinkering with Contents/Resources/json and Contents/Resources/svg, buried somewhere inside the VMPC2000XL.app bundle. On other systems, you would have to start putting your programmer's hat on and build from source using Visual Studio 2022 on Windows or your favorite editor and toolchain on Linux. Alternatively, you could wait a bit, because I do plan to make it easier to make skins somewhere in the next 6 months.

Desktop stability

Although VMPC2000XL for iOS is still in TestFlight, the standalone and plugin versions for desktop computers are slowly but surely reaching acceptable levels of stability. Personally I rarely experience VMPC2000XL crashes these days, and most support requests of the past few years do not involve crashes or freezes either. That said, I'm not a professional producer who has used VMPC2000XL for many hours without any serious issues. So the compromise is to remain in alpha (pre-beta) stage, but getting ready to promote to 1.0 beta hopefully in 2025 or early 2026. This is what the big jump to 0.9 signifies.

Improved multi-bus plugin support

If you've tried VMPC2000XL's multi-bus support, most likely you have seen vague bus names and reached for unavailable buses. The truth is, multi-bus is surprisingly difficult plugin territory.

Let's start by describing the ideal scenario, where VMPC2000XL is king in the world of music software:

VMPC2000XL has 4 mono input channels and 10 mono output channels. This reflects the capabilities of the real MPC2000XL with an output expansion board: RECORD IN L/R, DIGITAL IN L/R, STEREO OUT L/R, ASSIGNABLE MIX OUT 1 to 8.
Input and output 1/2 can be used by the user as individual mono channels, or as single stereo pairs. The same for 3/4, 5/6, 7/8 and 9/10.
Regardless of how the user wants to use/view the inputs and outputs, it is always clear which input or output of the virtual MPC2000XL they're dealing with, so names like "RECORD IN" and "MIX" should be clearly visible when selecting buses in the host's interface.

But it's quite a challenge to fit this ideal to the real world.

All plugin formats -- LV2, VST3, AUv2, AUv3 -- have their own ideas regarding channels and busses in plugins and hosts. And so do all hosts!

One of the problems as a plugin developer is there's no central place that aggregates the capabilities of each plugin format and host combination. So you're kind of forced to try and get as close as you can to the ideal, for every single one of these combinations. And it turns into a bit of a waterbed, where fixing one combination leads to breaking another one.

The final result is presented in the updated plugin compatibility matrix.

Overall, all the multi-bus fixes in v0.9.0.0 release candidate 0, combined with consulting the compatibility matrix, should lead to a good multi-bus experience.