Originally Posted by: dmansfield

I jumped in with Silicon because I need it for my workflow, my DAW no longer fully supports my 5,1 Mac Pro. I'm trying to figure out a strategy for getting along without a native M1 version of VEPro 7.

I've seen mention of the AU plugin working natively under Silicon-- is that correct? If so, is it possible to use it in Pro Tools and DP11? I imagine not, as people would be doing it, but if so, I could still run all my VSL software on my 5,1 slave.

If not I can run everything that's NOT vsl on my Mac Studio and give up my vsl libraries. Unless there's some convoluted way to get MIDI to VEPro 7 on my slave using Audio MIDI and the MIDI networking feature.

For example, could I run some kind of simple DAW in input mode on the 5,1 slave with the VEPro 7 plugin running, connected to the VEPro server on the same slave, and then send MIDI to the DAW from my Mac Studio? I could get the audio back to the Mac Studio either with Bidule or ADAT lightpipe between the slave interface and the master interface (MoTU 828es and 2408 Mk III). Is this crazy???

I can in fact confirm that AU plugin of VEP7 WILL work in DP when DP is run in native mode.  Just not MAS.  So you could build a template entirely out of AU instances of VEP connected to your server.  The problem with that of course is just that AU plugins won't allow for multiple (up to 48) midi ports like MAS so you need A LOT more of them if you intend on building a large template.

Originally Posted by: Ben

I am not part of our support or marketing team. This is a user forum; if you like to get support here is our official support channel:

I do my best to be helpful in forums just because I like doing music and I also like our products.
And just because I don't use an Apple device I "deserve this dressing down"? No thanks, I'm happy to leave this conversation. Have a nice day.

Hi Ben, I just wanted to say that while i share Michael's frustration about how long it's taking VSL to get an AS Native VEP going, that frustration is ENTIRELY directed at VSL and I have nothing but gratitude for your chiming in with an update when all we've been getting is silence from VSL for months.  While I'm frustrated by the VSL silence that's not your fault!! and I think there's a bit of unfair "shooting of the messenger" going on here.  I hope you'll continue to post on this forum and keep us updated as it really helps and does not go unappreciated.  Thanks, Evan.

Hi Ben, this update is seriously appreciated!  Thanks!  Good luck to the entire team.  Wishing for a speedy and smooth transition to AS Native!

Cheers,
Evan

Right Click anywhere in the area across the top where the instances are, then select "switch instances list orientation"

Cheers,

Evan

This problem dates wayyyyyyy back to VEP7.0.1120 and I read it was fixed in newer (ilok) versions of VEP7 but I just made the switch to ilok and installed the latest version - 7.1.1406 and I STILL can't open saved .vesp64 files directly from finder.  If I open them, they just open the VEP app and then it loads a blank new file.  I have to either:

1 open the app first

2 THEN either open the file from finder, or IN VEP, go to file>open.

Prior to 7.0.1120 we could just simply double click any .vesp64 file and it would open the APP and THEN the file we wanted.

Using latest version of Monterey 12.6.1 on MBP m1 Max.

haha same.

Hi Jeff, I doubt very much you want to look into switching DAWs at this stage but for what it's worth, VEP7's multiport MAS plugin is working fairly well for me with DP11 (in rosetta mode)..  As long as I launch DP11 in rosetta, VEP's MAS plugin shows up and it will successfully load all my past templates, all with multiple midi ports (I use 18 midi ports per instance, each with 16 channels).  Cheers, Evan Goldman.  Still, I'm counting the days til VSL releases apple silicon native VEP!!!

Out of curiosity, did updating VEP somehow enable "coupled" instances?  - which can DRAMATICALLY increase save times depending on your templates.  Or are you seeing this beach ball everytime you save with your VEP instances UN-coupled??

Anyone try the new VEP ilok released today? (June 02) and see if MAS and DP are finally playing nice?  (not to mention opening and connecting to pre-ilok VEP projects?

Evan

In my experience, when the button on the plugin is LIT (orange) (or the little RED button to the right of that is LIT RED), that means you are UN-coupled.  The orange button un-couples only THAT instance while the little RED button un-couples ALL VEP instances.  If both of them appear gray (UN-lit/colored), that means they are coupled.

I'm pretty sure you've encountered a bug I was about to report however, I don't think it's a data loss bug, but rather a subtle but really problematic SAVING bug?  Or maybe I've encountered a slightly different thing....

Let's say you're working with a VEP file called "Template A" and you choose to import instances from "Template Z"

The very next time you go to Save As, it DEFAULTS to calling your file "Template Z" and saving it in the SAME location as Template Z.  Which means, if you aren't careful to NOTICE and CORRECT this, it will SAVE OVER "Template Z" with the NEW (potentially totally different except for whatever instances you just imported) from Z.

This is HIGHLY problematic, counter-intuitive, and should be fixed in my opinion RIGHT away.  Just because I want to import an instance from Template Z (saved on drive/folder Z), doesn't mean I've now totally abandoned working on Template A (saved in drive/folder A).

Evan

I've heard from numerous colleagues that the ilok version of VEP MAS remains very broken (whether using 1263 or 1298).  Major difficulty opening old projects, constant pops, crackles.  Curious if there are any updates on the efforts to fix this?

Originally Posted by: Paul

Hi everybody, 

We're on it, thanks for your patience!

Best, 
Paul

Hi Paul,

Really appreciate that you guys are on this.  I gotta say, I can't help but feel like so much of these headaches could be avoided if VSL had a few DP users on the beta testing team.  I'm a beta tester for MOTU/DP itself and there are so many bugs that our beta testing team help MOTU squash before each release.  Makes such a world of difference.  I really wish VSL would consider adding me to the VEP beta testers community.  If not me then other DP/VEP power users please.

Thanks for the consideration.

Evan Goldman

I'm hearing similar identical reports from fellow DP/MAS/VEP using friends.  I think its safe to say that ilok VEP MAS still doesn't work correctly yet.  Hopefully VSL is reading this and working on a fix! (fingers crossed).

Evan

Originally Posted by: bkshepard

I'm using the latest versions of both VEP and Digital Performer on a Mac MINI OS 11.6.5. When I try to use the MAS plugin to connect to the server, I get horrible latency and data drops. I can press a key on my MIDI keyboard several times before it actually triggers a note and then it's delayed by about a half second. It also frequently misses the note-off messages so I get a lot of stuck notes. Connecting with either the AU or VST plugin works fine. Am I doing something wrong? I thought the MAS plugin would work even better within the DP environment.

Hmm, I've been using DP w VEP7 MAS for years and it's always been quite stable and responsive. though I haven't updated to the ilok version of VEP yet.  Are you using the brand new ilok VEP7 by?  (anything post 7.0.1120)?  Wondering if maybe you've uncovered more buggy behavior with this ilok transition.

+1.  Same problem.  Worked fine in MacOS PRIOR to 7.0.1120

Originally Posted by: dmansfield

Originally Posted by: evang42

I also use DP11 and am a beta tester and can report issues directly to the MOTU devs. What are the steps/circumstances that cause the midi timing bug w DP11/VEP you’ve found on intel???? This needs to be fixed asap regardless of AS transition.

With higher buffer settings (e.g. 1048), if you are routing a MIDI track to a VI (any VI, even a MoTU VI), MIDI records about 60 ms late. Also "Fine-tune Audio I/O Timing" does not work on these machines. The only workaround is nudging MIDI back into place after recording. I've been working extensively with Matt Batson in tech support, and the engineering team has been made aware of the bug. They have reproduced it on 2 different Intel machines, and confirmed that it does not happen on their AMD PC or their M1 Mac Mini. I don't know that it is a priority for them though.

There is an extensive thread about this on MoTUNation, "MIDI recording late", where I document what's going on in detail (though you may have to wade through some off-topic or uninformed posts to see it). If you have access to the engineering team and can help nudge them toward supporting the older Intel machines, that would be great!

Hi dmansfield!  I found an answer/fix for you on this!  In DP's preferences, go to midi options and UN-check the box called "Sync Recorded Midi to Patch Thru".  This SHOULD totally fix your issue (on ANY machine, apple silicon, intel, pc etc).  It's a setting that tells DP to place midi either 1) exactly where you PLAYED/intended it (un-checked) OR 2) where you would normally HEAR that midi (which of course is dependent on buffer size/latency).

To be clear, DP11 itself is fully AS native, but as you point out VEP MAS won't work in Rosetta.  I actually spoke to someone at MOTU about this and they said that Rosetta could only translate AU plugins (and not MAS) so unfortunately it's up to VSL to go AS native and deliver a MAS version to get this working again and it seems there's nothing more MOTU can do.  

Originally Posted by: Dan Wool

Originally Posted by: evang42

WOW.  mind absolutely BLOWN.  Thank you so much for bringing this to my attention.  This has long plagued me too!!  But I had no idea until 20mins ago that this was an actual bug effecting only DP users.  I incorrectly thought this was just the very nature of latency and buffer settings etc and all DAWs experienced this.  Just confirmed with Logic and Cubase using friends that those DAWs will compensate for higher buffers when live recording MIDI.  DP needs to fix this RIGHT AWAY.  I'm going to ping the hell out of this to the dev team.  Thanks again for bringing to my attention!

Wait, what? I've used DP exclusively for composing with MIDI for years. Are you saying other DAWs have found a way to eliminate buffer latency when recording MIDI (IOW the interval between the time a key/pad is pressed and the VI sounds)? If so, I missed a memo, because it was not always so. Back in the oughts, when I used Logic, latency was definitely a thing.  

No no, theres a very clear distinction that needs to be made here.  I'm not saying other daws found a way to eliminate the buffer latency of - the interval between the time a key/pad is pressed to the time you hear the sound - that would basically be impossible.  What Im saying is other DAWs have a way to place the actual MIDI notes that you play in real time down in the midi track at the EXACT time you physically touch the keyboard, regardless of buffer.  Pretend your speakers are muted for a sec, this whole thing has nothing to do with actual sound.  Set up a metronome on your iphone or something.  Now, If you record arm a track in Logic or Cubase, play a midi passage to the click at a buffer of 64, the resulting recorded midi will be in time to the same extent that if you then change your buffer to 2048, record arm the track and play to the same click.  That is currently NOT the case w DP.  DP's buffer settings are having a negative delay/impact on where the actual midi notes get put while recording and it gets worse the higher the buffer goes.

WOW.  mind absolutely BLOWN.  Thank you so much for bringing this to my attention.  This has long plagued me too!!  But I had no idea until 20mins ago that this was an actual bug effecting only DP users.  I incorrectly thought this was just the very nature of latency and buffer settings etc and all DAWs experienced this.  Just confirmed with Logic and Cubase using friends that those DAWs will compensate for higher buffers when live recording MIDI.  DP needs to fix this RIGHT AWAY.  I'm going to ping the hell out of this to the dev team.  Thanks again for bringing to my attention!

Seriously cannot WAIT for this.  (both the ilok transition and the AS native MAS VEP).  So excited.  

+1.  Really hope we getting closer to this as it is so crucial to my and many others' workflows.

I know ilok is the thing that's been holding everyone up to an extent....

Though, I'm seeing some chatter that ilok FINALLY has this stuff together and a bunch of ilok dependant developers now finally have public beta builds which I'm HOPING means VSL is nearing their big ilok switch.

Continuing to keep my fingers crossed.

Evan

Any updates on this VSL?  Are we at least getting closer?  I can't put into words how badly I need Apple Silicon native VEP and MAS-plugin for my workflow.  Sending all the well wishes and good vibes to the entire dev team!

Evan

Originally Posted by: Paul

Hi guys, 

We'd love to get to M1 upport right away and it is high on our list, but the transition to iLok is our top priority right now. 

All our developers are working on Mac and have done so for years. It doesn't matter to us which OS our users prefer. 

Best, 
Paul

I'm sure it doesn't help that PACE is taking their sweet time to release m1 native build and all the various support files developers need to build their own m1 native versions.  Seems like every single developer that relies on iLok has been at a standstill for the past year as far as I can tell, just waiting on PACE.