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 ?
4 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?)
1 Like
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.
1 Like
Exactly! Temporal resolution.
That is encouraging 
. I’ll try it as soon as it available for not clients.
1 Like
(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 
)
1 Like
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?
2 Likes
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:
2 Likes
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…
2 Likes
Ok, back at my Osmose, Here a test with Bitwig 5.3.13 on my music MacBook (MBP 2014, Big Sur. Which means Bitwig 5 is the last version that will run on this notebook, version 6 requires macOS 12 or newer 
)
Here 64th at 120 bpm played from the internal arpeggiator of the Osmose (firmware 2.1.21, midi over USB in MPE mode, external midi clock from Bitwig):
Looking good! And 64th at 120 bpm are 32 notes per second, I guess at that level human playing precision is the by far most prominent factor
So it might be worth to investigate the recording chain (MIDI hub? Potential software side midi routings?), I see no indication of practically relevant temporal resolution restrictions in Bitwig itself.
Edit: Repeated the Musescore->IAC Bus (macos equivalent to loopmidi)->Bitwig experiment from above on the Macbook. Getting comparable results, so it’s apparently not so much my Windows machine, but really Musescore. (Is Musescore perhaps trying to “humanize” playback? Or precision beyond common requirements for real pieces was just no focus…)
1 Like
Im hesitant to make this post because of all the time and effort you put into testing older versions, but I dont think it was note on timing that was the issue people complained of in the past, I think it was the nuances of what happened to the MPE expressive data (CC74, channel aftertouch, and perhaps also pitch bend). And you’d need to be trying it with the right sort of Osmose sound preset, one that was sensitive to some of that data in away that would obviously transform the nature of the sound when played back using the recorded data. And I wasnt one of the people who ever tried this, in fact for various non-Bitwig reasons Im never that keen to control Osmose via recorded MPE in the first place.
1 Like
Ok, so not temporal resolution?
Think it would be best if the people who had the problem in the first place retest with the new version and concretely describe what they do and what they observe to make this reproducible.
Edit: Sorry for derailing your initial thread, will pull the related postings out into a separate topic.
1 Like
Temporal resolution of pitch bend, CC74 and channel aftertouch data, rather than note on/off data is my assumption. And/or any smoothing/slewing of that data that Bitwig may have used to compensate for possibly less data points over time in Bitwigs own version of these message data streams. But you are correct that we need people who actually suffered this issue in the past to join in.
Dont worry about thread derail, we can cover everything here OK I think
1 Like
Also because Osmose was the thing that made some people complain, we also cannot I suppose rule out a different issue, eg if its not actually a temporal resolution problem but rather the loss of value resolution caused by normal MPE instead of MPE+ that Haken use.
Whichever of these causes is the underlying issue, It will be Haken preset specific as to whether this shows up to peoples ears for specific presets that made heavy use of CC74 and/or channel pressure to influence things like the attack phase of sounds in some presets.
1 Like
Hm, I would (perhaps naively) have expected that a DAW is recording the (already discrete) midi events exactly as it gets them. Decimation / deadbanding etc. is helpful for data reduction on timeseries data when you have to save disk space - and you know what you are looking for, so the crucial information survives. So I see no reason why a DAW shoulld do this?
But as said, naive assumptions
If somebody has made experiments - please repeat with version 6 and report
1 Like
Well to return to original reason why I hoped 6 might have changed this, it was down to a non-MPE user who had previously complained that bitwig automation data in general was not as ‘snappy’ when modulating parameters as the modulation they could obtain by using Bitwigs modulation system instead of automation data. And in a long 6 beta launch stream, they seemed happier with what they were getting from automation lanes in 6 than they were in previous versions. So I took some of the underlying concepts from this and considered that they may also apply to MPE data.
Data size is one of the reasons why a DAW may not store data exactly the same as it received it, but there are probably others too. eg stuff relating to the editing of per note MPE data visually using the DAWs UI & associated curve editing tools.
1 Like
And when I go on about the manual creation or editing of that data, this certainly overlaps with new stuff in 6. To the extent that these days when it comes to general automation data in Bitwig 6 and various improved tools to manipulate or generate it, they have even introduced the ability to freely drag and drop automation curves into some of their other systems such as the MSEG feature that they originally added much longer ago. This also means there is now some interoperability between their automation lanes and other sorts of modulation systems, seemingly in both directions. When I get a chance to try this stuff for myself, I will of course be checking to make sure that all this new stuff that applies to automation lanes in general, also applies to MPE per-note data.
1 Like
Well, in that case I hope they introduce a “record as you got it” mode. I honestly consider MIDI tracks like audio tracks and rather re-record instead of editing around. So staying as close to the original recording as possible would imho be best. (at least as an option).
That said, haven’t realized any such problems myself yet - but I was not actively looking for them, if they existed they were not obvious enough (or I not sensitive enough to detect them )
1 Like
For a long time I knew we werent actually dealing with ‘record as you got it’ with certain DAWs, because of different issues with MPE. Some DAWs are ‘MPE agnostic’ in that they just pass all the MIDI data through, but DAWs like Bitwig and Ableton have always been ‘opinionated’ when it comes to MPE data. They are MPE-aware and treat such stuff in a special way, probably for numerous reasons. This means messages in MPE MIDI streams that dont fit the standard narrow definition of MPE, eg additional per-channel CC’s other than CC74, are often thrown away. And these DAWs are also doing their own dynamic MPE MIDI channel allocation, not just relying on the MIDI channels that the MPE controller originally used. There are a number of reasons for that approach, including scenario where you want to overdub MPE data into an existing MPE track and dont want channel conflicts between new data and existing data to mess things up. And also so they can allow users to specify a narrower range of MPE channels to use when sending data to specific external synths (eg some Sequential synths that have 6 voices and only respond to 6 specific MPE voice channels in MPE mode). And so they can let users enter MPE notes from scratch in piano roll etc without user having to manually specify what MIDI channels each note should use. Other reasons relate to curve editing tools in the DAW editor, or other decisions made in the past about data resolution. Finally, they may also have plugin SDK reasons to abstract some of this data, eg when dealing with VST3 & Clap per note expression data that is in its own abstracted format rather than being ‘pure MIDI MPE data’.
3 Likes
Some of those issues, including plugin SDK interface ones, come up again when we think about the DAW side of MIDI 2.0. The MIDI standards people are having to do an entire round of internal development discussions and additional standards ratification with interested parties in order to work out the best practices for handling the huge new world of MIDI 2.0 possibilities within the context of a DAW, plugin SDKs etc. Things get complicated quite quickly when various conflicting factors and requirements are thought about in full detail.
1 Like
Hey sorry for the delay, busy days 
I don’t think I can access the beta. I read this on the official announcement: " If you own a Bitwig Studio, Producer, or Essentials license with an active Upgrade Plan, you’ll find the beta installers in your user profile. " I only have the 8-track license. The problem was detected with a trial of Studio version. I’ll try as soon as they release it ^_^
But yeah @SteveElbows assumptions where correct. I only noticed the problem in certain “very percussive” patches. I don’t have access to my gear right now so I can’t confirm which presets were the most noticable.
And yeah, I was recording MPE+ and playing it back. I know there are some particular messages (CC84 if I remember correctly) that are not used un regular MPE. But those are used to increase the resolution of the values of other expressions (like CC74). But I don’t think that’s the problem here because, if I remember correctly, the EM prioritize temporal resolution on the attac (so no CC84 there).
My feeling is that DAWs tries to decimate midi events because it is harder to edit them. But that’s just my uninformed guessing. As @SteveElbows said, they have reworked the editor, so maybe that issue was corrected.
It’s definitely possible, Cubase does the round trip perfectly, and Ableton is close enough.
1 Like
