Roli: Equator 2 is here !

[SamDi]

I wonder if saving each preset as is in another DAW as a user copy would also work?

What could also an idea, to take a preset, when it’s loaded correctly and save it in BW as VST 3 preset. Maybe the restore process works better with this mechanism.

I was thinking along these lines also. Did you get to try it yet? Did you have success? BTW, I am not using the NKS patches (yet; I may be soon,) so I'll try from my end to see how it going more generally. It's difficult to imagine a hang-up specific to its use, but then it's kind of hard to speculate on why the issue exists at all.

Seems to work with VST3 presets, they seem to load correctly in Standard and MPE. But is PITA thoguh. Easier but proprietary approach would be to save it as BW preset. Checked it out and seems to work, too. Thus I need not to drag a vstpreset file on the device, but can go directly via the preset button. Anyway, I wouldn't have joy to save all presets like that. For me switching to twin preset and back is OK. And for the presets, which don't have a twin, OK there in the worst case you must go to another DAW, save as vstpreset and then load in BW.

[dlandis]

Sometimes you don't know what correctly loaded actually is though. Probably safer to save vst3 presets in another DAW.

Well, one can check a given patch loaded in BWS vs. the same patch loaded in another DAW (though one should attempt to match the output of each DAW to improve accuracy; BWS, for example, seems to have a lower default output than Studio One, so I adjust BWS for this discrepancy. Generally, though, it's been pretty obvious (now that I am aware that the problem wasn't just "weak preset programming" as I previously suspected) when a patch is loading up wrong.

[dlandis]

I wonder if saving each preset as is in another DAW as a user copy would also work?

What could also an idea, to take a preset, when it’s loaded correctly and save it in BW as VST 3 preset. Maybe the restore process works better with this mechanism.

I was thinking along these lines also. Did you get to try it yet? Did you have success? BTW, I am not using the NKS patches (yet; I may be soon,) so I'll try from my end to see how it going more generally. It's difficult to imagine a hang-up specific to its use, but then it's kind of hard to speculate on why the issue exists at all.

Seems to work with VST3 presets, they seem to load correctly in Standard and MPE. But is PITA thoguh. Easier but proprietary approach would be to save it as BW preset. Checked it out and seems to work, too. Thus I need not to drag a vstpreset file on the device, but can go directly via the preset button. Anyway, I wouldn't have joy to save all presets like that. For me switching to twin preset and back is OK. And for the presets, which don't have a twin, OK there in the worst case you must go to another DAW, save as vstpreset and then load in BW.

This is great to hear. I get that it's a pain, but it's at least workable. And, of course, there's no law that says one has to save literally all the presets. I wonder as well, if someone were to go through systematically and save all of the presets from within Bitwig, if those presets would solve the issue across the board for all Bitwig users or if this is more "machine-specific." I'd be willing to work through the patches and share them if this works as a fix as I am retired and have some time that I could spend on this.

[aMUSEd]

I wonder if saving each preset as is in another DAW as a user copy would also work?

What could also an idea, to take a preset, when it’s loaded correctly and save it in BW as VST 3 preset. Maybe the restore process works better with this mechanism.

I was thinking along these lines also. Did you get to try it yet? Did you have success? BTW, I am not using the NKS patches (yet; I may be soon,) so I'll try from my end to see how it going more generally. It's difficult to imagine a hang-up specific to its use, but then it's kind of hard to speculate on why the issue exists at all.

Seems to work with VST3 presets, they seem to load correctly in Standard and MPE. But is PITA thoguh. Easier but proprietary approach would be to save it as BW preset. Checked it out and seems to work, too. Thus I need not to drag a vstpreset file on the device, but can go directly via the preset button. Anyway, I wouldn't have joy to save all presets like that. For me switching to twin preset and back is OK. And for the presets, which don't have a twin, OK there in the worst case you must go to another DAW, save as vstpreset and then load in BW.

This is great to hear. I get that it's a pain, but it's at least workable. And, of course, there's no law that says one has to save literally all the presets. I wonder as well, if someone were to go through systematically and save all of the presets from within Bitwig, if those presets would solve the issue across the board for all Bitwig users or if this is more "machine-specific." I'd be willing to work through the patches and share them if this works as a fix as I am retired and have some time that I could spend on this.

It worked with the NKS presets so should work with Bitwig presets too

[dlandis]

It worked with the NKS presets so should work with Bitwig presets too

One would certainly think that; it doesn't seem as consistent in BWS, however. If you would be so kind to check my procedure: open a Standard preset (e.g.): Additive Elegance. Open the corresponding MPE preset: (also) Additive Elegance. Save this as: Additive Elegance BWS (e.g.) It saves to the user presets this way. So far, so good and the user saved patch sounds as it should.

This is true unless (as I have since found out,) one opens another patch unrelated to Additive Elegance and attempts to open the user saved Additive Elegance BWS directly (i.e., without opening another instance of Additive Elegance that is either Standard or MPE next before opening Additive Elegance BWS.) If one does do this, Additive Elegance BWS sounds very quiet and not much like it does when one opens Additive Elegance Standard (e.g.) before it. Opening another instance of Additive Elegance before opening the BWS edit remedies this issue.

In essence, if I'm interpreting this behavior correctly, Equator 2's presets always need to be "primed" by opening a "partner patch" in Bitwig (at least, if one exists.) I'll check to see if one can open the same patch twice to get the right sound. I haven't tried that yet, but it's worth a shot.

[dlandis]

It worked with the NKS presets so should work with Bitwig presets too

One would certainly think that; it doesn't seem as consistent in BWS, however. If you would be so kind to check my procedure: open a Standard preset (e.g.): Additive Elegance. Open the corresponding MPE preset: (also) Additive Elegance. Save this as: Additive Elegance BWS (e.g.) It saves to the user presets this way. So far, so good and the user saved patch sounds as it should.

This is true unless (as I have since found out,) one opens another patch unrelated to Additive Elegance and attempts to open the user saved Additive Elegance BWS directly (i.e., without opening another instance of Additive Elegance that is either Standard or MPE next before opening Additive Elegance BWS.) If one does do this, Additive Elegance BWS sounds very quiet and not much like it does when one opens Additive Elegance Standard (e.g.) before it. Opening another instance of Additive Elegance before opening the BWS edit remedies this issue.

In essence, if I'm interpreting this behavior correctly, Equator 2's presets always need to be "primed" by opening a "partner patch" in Bitwig (at least, if one exists.) I'll check to see if one can open the same patch twice to get the right sound. I haven't tried that yet, but it's worth a shot.

ADDENDUM 1: No, opening the same patch twice doesn't work: it seems to need the partner patch to load first to enable Equator 2 to load the correct sound. OTOH, I'm not entirely sure that single patches (those existing as "only" MPE or Standard without a corresponding counterpart) have an issue loading correctly, per se. I'll check that next, but will have to do that after supper in conjunction with Studio One.

ADDENDUM 2: There seems no correlation between patches with partners and those without: while there do seem to be a few patches without partners that load correctly (though, of course, I could easily be missing some small detail,) many simply do not load correctly at all, I'm sorry to say. At least the partnered patches can be fixed with the double load of Standard and then MPE patches (or vice-versa.) Non-partnered presets that don't load correctly are essentially "dead" unless one wants to check what is in error by comparing instances of the same patch in two different DAWs. It seems that most of the loading errors I've seen occur in the FX section, but I'm not sure if that accounts for literally "all" of the loading errors.

It seems that ROLI has some work to do. Although this problem occurs only in Bitwig, it is not clear that this either a Bitwig problem or that Bitwig has the necessary resources to fix this issue. Also, I received back a note from Bitwig to this effect. ROLI has not responded at all to my note from yesterday, but, giving them the benefit of the doubt, it is only one day. Why they don't test Equator 2 in Bitwig (as it was one of the earliest and best adopters of MPE,) is a mystery to me. The idea that one should abandon Bitwig in order to keep using Equator 2 (as one poster noted a ROLI representative suggested to him, especially given the fact that this is a problem only experienced with Equator 2,) is probably patently absurd for most. There are currently many options for the use of MPE, some of which cover the same basic sonic territory as Equator 2. It's my guess that a simple incompatibility between Equator 2 and Bitwig will not cause many to give up Bitwig, FWIW. I can't speak for anyone else, but I was planning to buy the Seaboard Rise 2 eventually (I'm waiting for some nonmusical legal issues to come to a conclusion.) At this point, I'm beginning to re-evaluate my options. I may still buy the Rise 2. The way ROLI resolves this issue will definitely be factored into my final decision.

[MegaPixel]

ROLI has not responded at all to my note from yesterday, but, giving them the benefit of the doubt, it is only one day. Why they don't test Equator 2 in Bitwig (as it was one of the earliest and best adopters of MPE,) is a mystery to me. The idea that one should abandon Bitwig in order to keep using Equator 2 (as one poster noted a ROLI representative suggested to him, especially given the fact that this is a problem only experienced with Equator 2,) is probably patently absurd for most. There are currently many options for the use of MPE, some of which cover the same basic sonic territory as Equator 2. It's my guess that a simple incompatibility between Equator 2 and Bitwig will not cause many to give up Bitwig, FWIW. I can't speak for anyone else, but I was planning to buy the Seaboard Rise 2 eventually (I'm waiting for some nonmusical legal issues to come to a conclusion.) At this point, I'm beginning to re-evaluate my options. I may still buy the Rise 2. The way ROLI resolves this issue will definitely be factored into my final decision.

Roli took weeks to respond to me. Then when they did respond they asked for proof and it was another week or 2 for them to respond to that.


Here's another bug
Not an issue in other MPE capable VSTs, only Equator 2.
Note that the dashboard reports what I am doing on the Rise 2 correctly, but equator 2 doesn't.



Roli's response: "In terms of the Glide point, you need to have Glide turned up more than 0 for it to work properly. Simply move the fader up slightly as you have shown in the video and it will work fine".

This was a WTF moment for me, as I set glide to 0 on the Rise 1 and EQ1 so I could play the Rise like a classic keyboard as it snaps to the closest note. I didn't expect it to jump to a random note often over an octave away. It saved me switching controllers all the time.

Luckily a glide value of near zero allows what I want to do, it also allows you to glide/roll your fingers up and down the main area of the rise 2 keyboard, if at 0 you can only use the strips at the bottom and top which will bug out (I don't think the sensors in the upper and lower strips are as accurate as they were on the Rise 1 either).

NOTE: Glide 0 will still disable the main keyboard area in other VSTs.

This is just lazy programming...

[aMUSEd]

It worked with the NKS presets so should work with Bitwig presets too

One would certainly think that; it doesn't seem as consistent in BWS, however. If you would be so kind to check my procedure: open a Standard preset (e.g.): Additive Elegance. Open the corresponding MPE preset: (also) Additive Elegance. Save this as: Additive Elegance BWS (e.g.) It saves to the user presets this way. So far, so good and the user saved patch sounds as it should.

This is true unless (as I have since found out,) one opens another patch unrelated to Additive Elegance and attempts to open the user saved Additive Elegance BWS directly (i.e., without opening another instance of Additive Elegance that is either Standard or MPE next before opening Additive Elegance BWS.) If one does do this, Additive Elegance BWS sounds very quiet and not much like it does when one opens Additive Elegance Standard (e.g.) before it. Opening another instance of Additive Elegance before opening the BWS edit remedies this issue.

In essence, if I'm interpreting this behavior correctly, Equator 2's presets always need to be "primed" by opening a "partner patch" in Bitwig (at least, if one exists.) I'll check to see if one can open the same patch twice to get the right sound. I haven't tried that yet, but it's worth a shot.

Yeah you are right I guess the fundamental instability of presets in Bitwig muddies the waters. The NKS were just saved in Komplete Kontrol standalone. In that case what I suggest then is to try saving presets in .vstpreset format in a host you know Eq2 is stable with, then those could be loaded through Bitwig's browser

[aMUSEd]

Just tried that using Studio One to save out .vstpresets and it works

[Echoes in the Attic]

So who here wants to split up the saving of vst3 presets of equator?

Shame to lose all the attributes and ability to search though. Maybe KK is a better option.

[aMUSEd]

So who here wants to split up the saving of vst3 presets of equator?

Shame to lose all the attributes and ability to search though. Maybe KK is a better option.

If we split it by category and bank then it should be easier to give them some organisation

[Echoes in the Attic]

Oh woah, I just had equator loaded in Abelton Live 11, and I switched to the 12 string guitar from another synth patch and it was totally distorted and loud. switched away and back and it was normal. So not just in Bitwig! But I haven't been able to reproduce again in Ableton, though I can't tell if there are more subtle problems happening. Hard to know if a given preset is exactly as intended!

[dlandis]

So who here wants to split up the saving of vst3 presets of equator?

Shame to lose all the attributes and ability to search though. Maybe KK is a better option.

If what I've experienced is any indicator, saving wouldn't help those presets without "partners" that don't load correctly and even saving the partner presets may not wok (at least consistently, I'm sorry to say.) Once one switches to another (non-partnered) preset, it appears that all bets are off as far as loading correctly. At best, there is still much inconsistently. (I was, BTW, going to save all the presets myself and if they offered a fix, share them, but I'm pretty sure that would be a worthless endeavor now.)

OTOH, I received a very pleasant reply from a ROLI tech, apologizing for the loading problem, and stating that they were attempting to fix the issue in Bitwig (and Live?,) while also assuring me that the problem would be fixed before the next update. So, there is hope.

[aMUSEd]

So far all presets saved as NKS work fine, so do the ones I've saved as .vstpresets, regardless of whether they have 'partners' (which I don't see how it could make a difference anyway). You do need to make sure that the instrument is fully loaded before saving in another format though - we had a few NKS patches that weren't loading the sample and realised it's because you need to allow time for the samples to fully load

[dlandis]

So far all presets saved as NKS work fine, so do the ones I've saved as .vstpresets, regardless of whether they have 'partners' (which I don't see how it could make a difference anyway). You do need to make sure that the instrument is fully loaded before saving in another format though - we had a few NKS patches that weren't loading the sample and realised it's because you need to allow time for the samples to fully load

I don't get the "partner" thing either, but it seems to make a difference on this end (not using NKS.) I wish I understood it as I have a feeling that this might be helpful in troubleshooting this issue. I wonder as well if releasing a CLAP version might be helpful.