Menu
What's new
By:
Filters

Metagrid Pro and VEPro Big Problem

O

octave music

Member
I'm curious what Metagrid's user base is like so figured I would ask here.
I love Metagrid Pro on my iPad and use it extensively with Digital Performer as well as being my primary articulation switching platform.
About a year ago or so, when the Metaserver app got updated, I started noticing that Metagrid was no longer working properly. Something changed in the way Metaserver was passing data.

I have been able to reliably trace it down to the fact that when VEPro is open in the computer, and particularly, the front most app, it seizes any and all Metagrid commands. I have notified both Metagrid and VEPro about this and they say they are taking a look at it. It's been a LONGGGGGG time and perhaps there simply aren't many people experiencing this Metagrid/VEPro conflict.
So, I'm wondering:
is it "just" me and I think 2 other people I've found on the Metagrid forum that have this issue?
Metagrid told me they think that VEPro is taking over more "ports" than it claims to be taking, and that Metagrid is designed to simply find an open port to communicate on. Having VEPro in the background isn't a full proof solution. It's as though Metagrid/Metaserver fall asleep and stop passing through commands. This is not an issue with it disconnecting. I am connected via USB. I have used MIDI Monitor to watch the MIDI commands when I push on buttons in Metagrid and they don't show up in MIDI Monitor when VEPro is front and center.
Anybody else experiencing this?
Click to read more...
 
I’ll chime in by saying I have not seen this behavior on Mac OS with VEP and Cubase. However , I have had metagrid pro just stop sending any midi messages on a few occasions (3-4 times over the last year… so… very rare). A quick restart of the computer and close out/ relaunch of the app on the iPad has resolved it each time. I have not been able to purposefully reproduce this behavior.

Also….

When you create a button with a macro, you can choose which app should receive the macro toward the bottom. When I built my last metagrid scene I made sure the target apps were pointed to throughout every button so regardless of what app is in focus on my desktop, the command is sent to the proper app. Though I have seen times where an app in the foreground can temporarily break a connection to another until I bring the desired app back to the foreground. Just a side note.
 
I use TouchOSC and haven’t experienced this. I’m able to stipulate a port. As well as an IP.

Can’t you take metagrid off auto port search and manually define one?
If not the developer should be able to implement that easily. Perhaps there’s a way of doing in the backend config file.
 
Kslovelace said:
I’ll chime in by saying I have not seen this behavior on Mac OS with VEP and Cubase. However , I have had metagrid pro just stop sending any midi messages on a few occasions (3-4 times over the last year… so… very rare). A quick restart of the computer and close out/ relaunch of the app on the iPad has resolved it each time. I have not been able to purposefully reproduce this behavior.

Also….

When you create a button with a macro, you can choose which app should receive the macro toward the bottom. When I built my last metagrid scene I made sure the target apps were pointed to throughout every button so regardless of what app is in focus on my desktop, the command is sent to the proper app. Though I have seen times where an app in the foreground can temporarily break a connection to another until I bring the desired app back to the foreground. Just a side note.
Click to expand...
Thanks for commenting. I was able to have a friend 100% reproduce this issue on his computer with Cubase and VePro. Are you using the latest version of Metagrid, Ver 1.4 with Metaserver 4.1? I think when it was Metagrid Pro 1.3 and Metaserver 3.1.1–that for me was the last version that worked perfectly. But then my iPad auto updated to Metagrid 1.4 which required a higher ver of Metaserver, and since then it is a mess when VePro is running. I’ve experimented with the target app aspect and have found no difference in performance with that.
 
bcslaam said:
I use TouchOSC and haven’t experienced this. I’m able to stipulate a port. As well as an IP.

Can’t you take metagrid off auto port search and manually define one?
If not the developer should be able to implement that easily. Perhaps there’s a way of doing in the backend config file.
Click to expand...
I can’t even find what port Metagrid is using. I’ll have Metagrid shut off and do a full port scan in terminal, and then I’ll start Metagrid up and run the port scan again and it’s no different. So perhaps Metagrid isn’t using a port in the traditional meaning of the word.
 
octave music said:
Thanks for commenting. I was able to have a friend 100% reproduce this issue on his computer with Cubase and VePro. Are you using the latest version of Metagrid, Ver 1.4 with Metaserver 4.1? I think when it was Metagrid Pro 1.3 and Metaserver 3.1.1–that for me was the last version that worked perfectly. But then my iPad auto updated to Metagrid 1.4 which required a higher ver of Metaserver, and since then it is a mess when VePro is running. I’ve experimented with the target app aspect and have found no difference in performance with that.
Click to expand...
I am running the latest versions of both metagrid pro and and the server. I am on M2 Mac and Sonoma though. Not able to reproduce here. Tomorrow I can potentially try to bring up my older Mac Pro and try there to see if the issue pops up.
 
Wow you’re lucky. I had this issue when I was using a host/server setup with 2 separate late 2013 Mac pro’s and it persists on my macstudio M2 Ultra in Sonoma. I didn’t use migration utility when setting up my new computer in an attempt to solve this issue but it persists and like I said, I’ve had others replicate the issue—I wonder what you are doing right? Would you mind sharing/posting your main grid that you use for articulation switching or whatever grid you use when doing your music stuff. Maybe I could load that up and see if I get a good result.
 
octave music said:
Wow you’re lucky. I had this issue when I was using a host/server setup with 2 separate late 2013 Mac pro’s and it persists on my macstudio M2 Ultra in Sonoma. I didn’t use migration utility when setting up my new computer in an attempt to solve this issue but it persists and like I said, I’ve had others replicate the issue—I wonder what you are doing right? Would you mind sharing/posting your main grid that you use for articulation switching or whatever grid you use when doing your music stuff. Maybe I could load that up and see if I get a good result.
Click to expand...
Just a thought. As I still can not replicate on my 2013 MP either. If you bring VEP to the front and try press any key command (even just spacebar should work) VEP should ask permission to pass through data onto the DAW at the OS level. If you accept, any key commands that are not part of VEP itself get passed on to the daw. Which enables you to start and stop transport, etc. when VEP is the forward most application. Wondering if this has anything to do with it… as it seems we are practically running nearly identical setups. I believe it is the “input monitoring” permission but don’t remember exactly as it’s been I while since I have had to do a clean install of either cubase or VEP.
 
Kslovelace said:
Just a thought. As I still can not replicate on my 2013 MP either. If you bring VEP to the front and try press any key command (even just spacebar should work) VEP should ask permission to pass through data onto the DAW at the OS level. If you accept, any key commands that are not part of VEP itself get passed on to the daw. Which enables you to start and stop transport, etc. when VEP is the forward most application. Wondering if this has anything to do with it… as it seems we are practically running nearly identical setups. I believe it is the “input monitoring” permission but don’t remember exactly as it’s been I while since I have had to do a clean install of either cubase or VEP.
Click to expand...
Thanks for thinking about this further. I enabled input monitoring but that didn't change anything. I also granted VEPro full disk access. One thing though that is strange, is that it lists the rosetta version of the app. I tried adding the native version but it still says rosetta. I wonder if that matters.
 

Attachments

  • Screenshot 2024-02-10 at 3.37.40 PM.png
    Screenshot 2024-02-10 at 3.37.40 PM.png
    25.2 KB · Views: 5
Last thing I can think of is… metagrid pro allows you to start from a blank content database which wasn’t the case with the old metagrid. Of which if you only import one grid/ scene but don’t assign it to a specific app… then in the background the active application changes but the scene you saved stays in front. I believe This breaks the connection to the app because metagrid believes it is targeting a separate application but visually nothing changes on the screen. In content manager, Make sure your workspace is actually assigned to a profile and linked to the DAW you are trying to control.

If this isn’t the problem then I really have no idea why you would experience this issue and others (or at least myself) haven’t.
 
Also, for input monitoring I would check your DAW as well. As it is for the background apps which would include your daw if and when vep is in front.
 
Kslovelace said:
Also, for input monitoring I would check your DAW as well. As it is for the background apps which would include your daw if and when vep is in front.
Click to expand...
Whoa man....standby...but I think you were on to something. I trashed the Rosetta versions of VEPro Standalone, and Server, rebooted my computer and now in the input monitoring, and full disk access sections of the system setup/security it no longer says rosetta....and now, well, I need to keep testing, but I think everything is working as it should. I'll report back...but holy cow!
 
Kslovelace said:
Last thing I can think of is… metagrid pro allows you to start from a blank content database which wasn’t the case with the old metagrid. Of which if you only import one grid/ scene but don’t assign it to a specific app… then in the background the active application changes but the scene you saved stays in front. I believe This breaks the connection to the app because metagrid believes it is targeting a separate application but visually nothing changes on the screen. In content manager, Make sure your workspace is actually assigned to a profile and linked to the DAW you are trying to control.

If this isn’t the problem then I really have no idea why you would experience this issue and others (or at least myself) haven’t.
Click to expand...
It is assigned. I use my grid exclusively in Omnispace. I don't utilize the app switching features of Metagrid.
 
octave music said:
Whoa man....standby...but I think you were on to something. I trashed the Rosetta versions of VEPro Standalone, and Server, rebooted my computer and now in the input monitoring, and full disk access sections of the system setup/security it no longer says rosetta....and now, well, I need to keep testing, but I think everything is working as it should. I'll report back...but holy cow!
Click to expand...
Forget it....didn't fix it. I opened up a real session and it's still completely unreliable. Having more trouble with it now in that it's not working reliably in DP. ONe of the input monitoring adjustments broke something.
 
the bottom line, kind of is this....once VEPro comes to the foreground, it's a matter of time, seconds, for when I can no longer click on the Metaserver icon on the menubar, because it's asleep/frozen or something.
 
You must log in or register to reply here.
Top Bottom