Massive changes and new features relating to automation and editing form the bulk of the headline new features in Bitwig 6.
Some of them are relevant to MPE. I will try to mention them all as I try each of them myself in the coming days.
The ones that really struck me and caused me to start this new thread involve the ability to add variation to the MPE data every time the clip is played back. To quote from the initial 6 beta release notes ( Testing Notes for Bitwig Studio 6.0 ):
- New features are also available for all automation points:
- Each point can have Hold behavior, staying at the current value until the next point is reached.
- Each point can have randomized Spread, setting a range where the point will land on each pass.
- Spread can be set from the Inspector, or by [CTRL]-[ALT]-dragging ([CMD]-[ALT]-dragging on macOS) up and down on a selected.
- For reproducible Spread results, automation clips have a Seed setting, as do automation lanes (for Arranger automation).
- Each point’s Curvature (the slope on the way to the next point) is now shown in the Inspector.
- This allows text entry for precise values.
- When multiple points are selected, this allows for group editing of the values, including use of the Histogram interface (with its Mean, Scale, and Chaos controls).
- Polyphonic event expressions and automation both have these new features.
So randomized spread in the context of MPE expressive data per note is the first thing I will be trying and reporting back on.
3 Likes
In January I tried Bitwig and I liked it a lot, but I didn’t jump on board because when I recorded the MPE from my Osmose I noticed a very big change in the percussive notes.
There was a big lack of resolution. I contacted support and they told me they were aware of the limitation and hoped to improve it in the future.
They don’t mention anything in the release notes, so I don’t have much hope, but just in case—have you noticed anything? Like a setting option to change the resolution of control points or something similar ?
3 Likes
Do you mean time resolution or velocity/CC value etc.? Which resolution did you get and which did you expect? (Did you e.g. experiment with high res MIDI and only got 127 values or was it less than that?)
They might be talking about temporal resolution.
I’m the wrong person to check if that improved because I wasnt using older bitwig versions with MPE in a context that was sensitive to that.
Theres a chance it might be improved now because a youtuber was trying out automation (rather than MPE specifically) in 6 and thought it was snappier in general now, so perhaps they have actually changed the temporal resolution. Someone who experienced the problem in the past needs to try with 6. I did mention this in the other existing bitwig thread before I started this new thread, because this issue was the last thing that got talked about in that other thread some time ago.
Exactly! Temporal resolution.
That is encouraging 
. I’ll try it as soon as it available for not clients.
(I guess?) every Bitwig customer gets a key for the „8 Track“ version to gift to another person. I have already gifted away mine, but perhaps somebody else might still have a spare one?
I guess the 8 track version should already allow to record MPE midi (for up to 8 tracks 
)
Just tried it out (via computer keyboard…) and cannot hear any audible difference in rhythm between what I played and what Bitwig recorded.
How did you measure/recognize the timing inaccurracies?
Perhaps you could trigger an arpeggiator with a known time pattern and measure the distances between recorded midi events?
Or do you mean time delay between e.g. an audio recording of the Osmose and the midi signals being recorded and sent back to the Osmose synth for playback?
1 Like
Ok currently out of controllers atm., so I did three experiments just with software (Win11, WASAPI sounddriver):
- Played notes in Musescore (half note, half rest, (quarter note (=120 bpm), quarter rest) * 2, … (64th note 64th rest)*32, output via loopmidi into Bitwig 6, recording there into a track. We see that 32th and 64th are not accurate anymore. Cannot tell from this experiment whether it is Bitwig, loopmidi or Musescore though…
- Connect a 50 ms gate repeat block to a note out in The Grid. Route the output into a separate instrument track, record that. Looks pretty even
- Same, with 5 ms gate repeat. (Zoomed in). Still looking even.
Unfortunately one cannot start several Bitwig instances apparently, so I cannot run The Grid in one instance and route it via loopmidi into another one.
My conclustion would be that the Bitwig internal midi engine can record with pretty high precision. But when recording external midi a lot of factors come into play (Midi source (here Musescore), transport (here loopmidi), OS (here Win11) etc.).
Would be interesting to repeat this experiment with the Osmose, a proper midi interface and e.g. a Mac (or an otherwise music optimized machine).
Edit: Here the last test (with 5 ms gate repeat in The Grid) with Bitwig 5.3.13 (even further zoomed in). I see no irregularities there:
1 Like
Here experiment 1 repeated with Reaper (Musescore → loopmidi → Reaper).
Looks like Musescore was not made for high precision playback. (Ok, 64th at 120 bpm (32 notes per second) is more unusual for realistic pieces).
And here Bitwig The Grid as MIDI note generator and Reaper as MIDI recorder.
First 10 ms then 50 ms gate repeats. Looks more like a bandwidth than a precision limit to me. The limits of this chain (Bitwig->loopmidi->Reaper) seems to be somewhere between 20 (no problem) and 100 (already too many) note events per second.
The other way around (recording external midi in Bitwig) would be more interesting for this thread, but I don’t know which reliable midi generator to use?
Anyways, testing with Osmose (or a similar controller) would be even more interesting anyways.
Last attempt was to generate notes with VCV. This doesn’t seem to work, no midi notes are being generated…
1 Like
