Studio One and MPE

[dlandis]

I have been quite annoyed (and, yes, I do realize that to a certain extent I'm venting) by Studio One's claim to implement MPE while conveniently leaving out parts of the spec. At this point, I think it's fair to say that Studio One is, at best, about 3/5 compliant as the fifth dimension, lift, has never been included in their implementation and glide (as verified to a techie) is crippled with a bug that reverts the pitch patches with long releases times back to the original pitch struck (i.e., glide from a Gb up to, say, a Db, lift your finger, and the pitch will immediately revert back to a Gb during the release segment of the patch.) Again, according to the techies, there is no plan extant to fix this bug (or the lift omission.)

And yet, Presonus quite deceptively claims to be compliant with MPE. The last time I checked, to claim compliance meant to embrace the full spec, not only those parts that were easily implemented or considered as more "popular." I'm left wondering in what other situations, Studio One's "implementation of MPE" breaks down. I'm also getting a bit tired wasting time trying to remedy these issues.

Does anyone have any ideas about how to hold Presonus' feet to the fire (at least regarding the deceptiveness of their MPE claims and their lack of integrity in advertising)?

[Funkybot's Evil Twin]

Uhm...stop giving them money until they fix it and encourage others to do the same?

[Vocalpoint Studios]

Where did you see/verify this:

"Presonus quite deceptively claims to be compliant with MPE"?

Admittedly - I do not know a lot about MPE in S1 (yet) - but willing to learn.

I see many comments out there saying that S1 "supports" MPE - but none that say it is 100% "compliant" with the entire MPE spec - which I agree - are two very different things.

VP

[runagate]

I think it's fair to say that Studio is, at best, about 3/5 compliant as the fifth dimension, lift, has never been included in their implementation and glide (as verified to a techie) is crippled with a bug that reverts the pitch patches with long releases times back to the original pitch struck (i.e., glide from a Gb up to, say, a Db, lift your finger, and the pitch will immediately revert back to a Gb during the release segment of the patch.) Again, according to the techies, there is no plan extant to fix this bug (or the lift omission.)

This is the sole reason I own Presonus [edit - I mean Studio One; I own lots of other Presonus things and like to give their mics as gifts to non-musicians). Thank you for ending my nightmare of trying to suss out what the hell was happening there. This is inexcusable.

How in the hell would cross-DAW projects with Bitwig be shared without MPE working? I almost bought Bitwig based on this idea.

[WasteLand]

i don't have Studio One, the glide is indeed a bug, all other MPE capable DAWs (certainly the DAWs i have) do glide well.

Live doesn't have Lift via Push 3, yet, while Push 3 can transmit Lift (Release Velocity). it does record it from other MPE surfaces/controllers...

i fully agree a MPE DAW must implement it completely, flawless (although there are differences between Live, Bitwig Studio and Cubase Pro, i have those, that only surface in specific situations. i think Live has the less compliant implementation, but i myself don't have problems with it, others have).

so it is strange that all DAWs do it in another way, Reaper's MPE can be imported into Cubase Pro, a midi file export. but Bitwig studio and Cubase, i think that does not work. it has to do mainly with the Midi channels.

[dlandis]

Uhm...stop giving them money until they fix it and encourage others to do the same?

Admittedly, this could work in the future (with a "critical mass" of users joining onboard if sufficiently motivated to do so.)

I was, however, speaking more of present action (fully cognizant that there certainly may not be any options to realize this objective.) Please accept my apologies for being less than clear in my original post.

[dlandis]

I think it's fair to say that Studio is, at best, about 3/5 compliant as the fifth dimension, lift, has never been included in their implementation and glide (as verified to a techie) is crippled with a bug that reverts the pitch patches with long releases times back to the original pitch struck (i.e., glide from a Gb up to, say, a Db, lift your finger, and the pitch will immediately revert back to a Gb during the release segment of the patch.) Again, according to the techies, there is no plan extant to fix this bug (or the lift omission.)

This is the sole reason I own Presonus [edit - I mean Studio One; I own lots of other Presonus things and like to give their mics as gifts to non-musicians). Thank you for ending my nightmare of trying to suss out what the hell was happening there. This is inexcusable.

How in the hell would cross-DAW projects with Bitwig be shared without MPE working? I almost bought Bitwig based on this idea.

Forgive me if I'm missing something, but I'm guessing a misprint? You mean to say that you do not own Studio One?

But you're exactly correct: if not all MPE dimensions are recognized, it should be assumed that those dimensions will probably not be recognized in imports from, say, Bitwig (which handles all MPE related tasks really well.) Sometimes, a DAW will allow for importation of parameters that it will not record in and of itself, but this tends to be kind of "catch as catch can," if you will. One certainly shouldn't count on it.

[dlandis]

Where did you see/verify this:

"Presonus quite deceptively claims to be compliant with MPE"?

Admittedly - I do not know a lot about MPE in S1 (yet) - but willing to learn.

I see many comments out there saying that S1 "supports" MPE - but none that say it is 100% "compliant" with the entire MPE spec - which I agree - are two very different things.

VP

A fair question.

Here is the second page of the application comparison chart.

You'll note that the comment at the bottom of the page is given without exceptions noted, hence the prima facie meaning (and one that Presonus seems to be banking on) is that the standard is fully recognized (and this, of course, certainly was what those who requested MPE as a feature expected was going to be implemented.) Moreover, a bug like the one that I am describing in as important a dimension as "glide" basically shuts down the use of MPE whenever the use of a patch with a long release is involved: i.e., pads and the like. And again, this is a bug. By their very nature, bugs imply an attempt at introducing a feature that is crippled to the extent of the nature of the bug, meaning, Presonus intended for glide to work correctly, but failed in the execution.

[Vocalpoint Studios]

You'll note that the comment at the bottom of the page is given without exceptions noted, hence the prima facie meaning (and one that Presonus seems to be banking on) is that the standard is fully recognized

Apologies but after seeing this chart for myself - I still just see the word "support".

It's difficult for me not to think you are making an assumption that fits the agenda - that exceptions are non-existent (on purpose) when really - at face value - none are required.

There is no evidence that the full MPE spec was intended for S1 (back in the 5.3 days) nor that "support" meant full (5/5) spec compliance.

Over in the Presonus forums - there was a thread in April 2023 that contained a link to a three year old Sound on Sound Article that clearly stated two interesting bits:

1. MPE is a major component of MIDI 2.0 so it’s important for DAWs to get on board with it.

2. The MPE implementation within Studio One is functional but doesn’t feel fully fleshed out yet

https://www.soundonsound.com/techniques ... orking-mpe

Both of these points make sense to me - espeically the MIDI 2.0 item - which will be a required element in the coming years. Presonus is known to be very particular (and insanely obsessed) about doing major changes right and really takes their time when something big (like ATMOS for example) finally makes it to general release.

Could be that MPE (as it is today) - is simply a precursor to much bigger things down the line (MIDI 2.0 plus a very vocal need to revamp all their S1 VST instruments) where the MPE spec in S1 will be "fully fleshed out".

But I get the frustration. I do not think it's on purpose - more like - "here's what we have now - start tuned".

I watched few vids on this - and it seems to do what it says on the tin. (for now).

VP

[dlandis]

You'll note that the comment at the bottom of the page is given without exceptions noted, hence the prima facie meaning (and one that Presonus seems to be banking on) is that the standard is fully recognized

Apologies but after seeing this chart for myself - I still just see the word "support".

It's difficlut for me not to think you are making an assumption that fits the agenda - that exceptions are non-existent (on purpose) when really - at face value - none are required.

There is no evidence that the full MPE spec was considered for S1 nor that "support" (whatever that looks like) constituted full (5/5) spec compliance.

For kicks - I just searched the entire 6.2 user manual and could only find 5 references to MPE at all. Given the very sparse mentions and a clear lack of any meaningful info - it doesn't appear that Presonus added this to set the MPE world on fire or is "banking" on anything.

What it looks like to me - is they added their vision of MPE support (3/5) to address a feature request (in the early v5 days) and that's it. Wouldn't be the first time that a DAW vendor put in "just enough" support for something and left it like that.

I watched few vids on this - and it seems to do what it says on the tin.

The bugs are another thing - and as with all potential defects - it would be great if they got some time.

VP

First of all, no disrespect is intended or expressed in anything that I write below; please be assured of that.

My point is that, at least as far as the layman is concerned (and very possibly even in more technically oriented circles,) there is no difference between "support" and "compliance" if exceptions are not noted. I do not doubt, for example, that there was no intention for Studio One to include "lift" in its support; I grant as much very willingly at the developer level. If I hadn't spent three weeks trying with two different Presonus techies to track down how to make lift work (as neither of the techies had any idea it wasn't implemented either,) I might feel a bit more charitable in assuming that no deception on a larger scale was intended. Obviously, your mileage may vary, but when techies are not aware of an omission, this should be a "red flag" that something deeper is amiss. I am simply arguing for specificity regarding just what or how many dimensions (and other parameters, for that matter) are actually implemented rather than issuing a nebulous statement which really adds to confusion and a waste of time, if not a purchase that does not measure up to one's expectations. When exceptions were made to what is supported in a spec, the onus is on the developer to be clear and upfront as to what was not implemented (rather than expecting the user to imply what isn't being supported via "silence" on a given parameter or dimension.)

Moreover, sir, on the point of "glide," however, the techie from whom I received a note to today was very clear in admitting the issue: it is a bug that it is not addressed. The developers are aware of it, but a schedule for the fix remains undetermined. There is no question that even as far as the company's expectation is concerned, the bug is not what was desired. There is also no doubt that the bug cripples the use of the glide dimension significantly. Presonus certainly may have intended to ignore the fifth dimension of lift; that certainly is probable, even if a dearth of notation of the same exists in manuals and the like. It is simply not the case (and quite frankly impossible given the way it effectively negates the use of glide in a significant number of situations) that the bug in the implementation of the second dimension was planned out. This simply needs to be fixed. In this, we are in agreement, although I am including this in the idea that Studio One "de facto" supports MPE only 3/5. The fact that such a fix is not scheduled, of course, indicates a low priority for MPE generally in the minds of the powers that be at Presonus.

Also, and very respectfully, I've not seen that Presonus is very obsessed about getting something right, per se. I say that partially because of what I've experienced regarding MPE, but also because the company's interest in a given area of concern seems to wane very quickly when another point of emphasis becomes "hot" for them. There was a situation with Notion where it didn't support i9 processors for quite a while (I bought Studio One and Notion partially because of the interaction that was promised, but, of course, the lack of support for i9 procs was not mentioned.) I do remember how long it took for the polyphonic aftertouch issue to finally become resolved. Though years ago, users were complaining (in a similar fashion what has happened with MPE) about its curious omission, it essentially took until the company's incomplete embracing of MPE for polyphonic aftertouch problem to be rectified (I say rectified because I believe I found at least one very narrow situation where it seemed to work and, yes, this was odd.). Was this their plan all the way along? Perhaps, but poly AT was hardly a new idea when people began complaining and it was only years later when it was solved.

Thanks much for the notes and your opinion.

[Vocalpoint Studios]

Though years ago, users were complaining (in a similar fashion what has happened with MPE) about its curious omission, it essentially took until the company's incomplete embracing of MPE for polyphonic aftertouch problem to be rectified (I say rectified because I believe I found at least one very narrow situation where it seemed to work and, yes, this was odd.).

Well - I still think that this "first cut" of MPE is just that (warts and all).

But it's not hard to theorize - that with NI hyping up their new poly aftertouch S-Series MKIII boards, the impending arrival (and soon to be required) support for all DAWS on MIDI-2 - not to mention the usual deluge of hardware AND software instruments that will hit the market behind MIDI-2 - got a feeling that Presonus will revisit all of this (and more) and tighten it all up accordingly.

VP

[dlandis]

Though years ago, users were complaining (in a similar fashion what has happened with MPE) about its curious omission, it essentially took until the company's incomplete embracing of MPE for polyphonic aftertouch problem to be rectified (I say rectified because I believe I found at least one very narrow situation where it seemed to work and, yes, this was odd.).

Well - I still think that this "first cut" of MPE is just that (warts and all).

But it's not hard to theorize - that with NI hyping up their new poly aftertouch S-Series MKIII boards, the impending arrival (and soon to be required) support for all DAWS on MIDI-2 - not to mention the usual deluge of hardware AND software instruments that will hit the market behind MIDI-2 - got a feeling that Presonus will revisit all of this (and more) and tighten it all up accordingly.

VP

And I sincerely and respectfully hope that your positivity is rewarded with both integrity and action from Presonus (and other companies.)

I do think it's weird that NI is touting poly aftertouch in their new series of keyboards. My Kurzweil Midiboard just died this past year. I can't tell you how many years I had it. I also owned an Ensoniq VFX (poly AT.) And, of course, MPE has been with us for about four years. To use the vernacular, poly AT "aint' no new thing."

As far as the MIDI 2.0 spec is concerned, however, I doubt there will be a deluge. We've hardly seen a trickle and I'm not sure who's requiring it (or more precisely, who actually has the authority to do so as the spec is not "owned" by anyone.) It was released in February 2020 and since that time, to my knowledge we've seen one physical keyboard w/o any aftertouch and one DAW (not a major DAW, but a DAW nonetheless) embrace it. I'm sure I'm missing something, but I think that while it will eventually happen (5 years or so, depending on the world economy which is fragile at best,) we've got quite a ways to go before it is commonplace.

[Vocalpoint Studios]

I do think it's weird that NI is touting poly aftertouch in their new series of keyboards. My Kurzweil Midiboard just died this past year. I can't tell you how many years I had it. I also owned an Ensoniq VFX (poly AT.) And, of course, MPE has been with us for about four years. To use the vernacular, poly AT "aint' no new thing."

Understood - but it is "new" for NI. And all their potential new customers of these new S-Series boards. That many other players (especially the big boys like Kurz and Ensoniq) had this eons ago is irrelevant to the NI crowd.

As far as the MIDI 2.0 spec is concerned, however, I doubt there will be a deluge.

To be honest - I never even heard about MIDI 2.0 until I really started following this whole NI MKIII rollout. But I do agree. There is a tiny bit of smoke now on this but no fire (yet). But one day - just when we think there is nothing going on - it will hit like gangbusters.

Exactly like ATMOS did. I remember 2-3 years ago - ATMOS was an obscure phrase reserved for nature presentations at the local IMAX theater and now everyone is yelling about "needing" it for their phones and DAWs and "immersive" this and "multichannel" that.

All in good time I suppose.

VP

[aMUSEd]

I do think it's weird that NI is touting poly aftertouch in their new series of keyboards. My Kurzweil Midiboard just died this past year. I can't tell you how many years I had it. I also owned an Ensoniq VFX (poly AT.) And, of course, MPE has been with us for about four years. To use the vernacular, poly AT "aint' no new thing."

Understood - but it is "new" for NI. And all their potential new customers of these new S-Series boards. That many other players (especially the big boys like Kurz and Ensoniq) had this eons ago is irrelevant to the NI crowd.

It's also not been exactly mainstream before, or available at the same price point you would pay for a standard aftertouch keyboard (ie the Poly AT S series are pretty much the same price point as the Series II). Also this is a traditional style keyboard, not something like a Seaboard, which will appeal to some, although whether that restricts the potential for implementing some MPE actions is a possible tradeoff. Most importantly though the old Poly AT keyboards existed at a time when there was no MIDI 2, standards have finally caught up, and this is one of the few keyboards to have both Poly AT and MIDI 2, which should enable more scope for DAW integration and interaction.

[runagate]

I bought that damned CME keyboard way back when just for the poly aftertouch, and I knew of only one other keyboard that was manufactured that had it way back when. Another chicken-and-egg issue in our field. MIDI supports it but no keyboards did so fewer and fewer sound-generators did. That CME keyboard had the charming feature of motorized faders that didn't update their automation... it just recorded once, and if you recorded again it overwrote what was there before. An amazingly pointless feature. Also, if you set something on them and they tried to move during startup when they'd move to calibrate it would burst into flames. Charming. So many things wrong with that thing's design.

I only just now realized neither my Nektar Panorama nor NI Kontrol have poly aftertouch, not that I care as I have a QueNeo, Roli and most importantly an Erae Touch which all do MPE. The Embodme Erae Touch is so by far the best thing I've ever bought and already supported MIDI 2.0 and is just waiting around for DAWs and VSTs to implement it.

Which will be a MAJOR change as the only cavil I have about this deliriously wonderful instrument is that you have to program it's various scenes of assignments in an app on the PC, rather than from the instrument itself. Two-way communication and MIDI Capability Inquiry (MIDI-CI) should solve that nicely, since it is basically a silicon low-rez LED touchscreen. Decades later than it should have been implemented, but I'll take what I can get.

https://embodme.freshdesk.com/support/d ... 0000660368

Hello,

The Erae is ready on the hardware side to run MIDI 2.0

We are just waiting for the MIDI association to finalize the specifications and more importantly to see some compatible plugins or hardware

As of now there is no point of finalizing our development as only Logic Pro embedded this feature and only to "enable MIDI2,0" without any other spec implemented...

But things are moving and we should see more and more products with this feature allowing us to move forward as well.